locked
A storage engine operation failed with error code 25133 during file synchronization RRS feed

  • Question

  • The sync framework 1.0 SP1 is returning the following exception for some of my application users:

    "A storage engine operation failed with error code 25133"

    I looked this up on MSDN and found the description, "Internal error: SQL Server Compact made an unsupported request to the host operating system."  The top of the table, however, has a note which says that if any of the errors described are prefixed with "Internal error:" Microsoft support should be contacted immediately.

    Does anyone know what this error is all about?  All machines are using the same version of the Sync Framework.  I realize its using an older version of the file sync provider, but, this only happens on a few machines.  Deleting the metadata file for each replica helps sometimes.  There are some in which it never helps.

    Thanks

    Tuesday, December 11, 2012 2:31 PM

Answers

All replies

  • any concurrent syncs ongoing?
    Wednesday, December 12, 2012 2:25 AM
  • There are no concurrent syncs.

    I did discover something interesting, however, in the folder pairs.  A user experiencing the error had 2 tmp files in the root of each folder.  The files are named FSP-{some guid in here}.tmp.  I thought I read that this is how the file sync provider stores a temporary object while an item is created/updated/deleted and subsequently added in the metadata file.

    In any event, once the user deleted those files in both the source and destination, the folders sync'd.  Is there any relationship between the persistence of the FSP- temp file and the 25133 error?

    Wednesday, December 12, 2012 6:22 PM
  • if you have leftover fsp files, then chances are you have an interrupted sync...

    also, have a look at the filesync part here: http://social.technet.microsoft.com/wiki/contents/articles/sync-framework-tips-and-troubleshooting.aspx

    • Marked as answer by f1ctc95 Tuesday, December 18, 2012 6:03 PM
    Thursday, December 13, 2012 3:14 AM
  • Thanks for the resource.  It doesn't indicate if there is a relationship between the interal error and the existance of the FSP.  We are going to look at some of our other clients reporting the error code and see if there is a similar situation.  I'll post results either way.
    Thursday, December 13, 2012 8:58 PM
  • the post I linked too mentions how to account for interrupted syncs.

    have you tried enabling tracing?

    Friday, December 14, 2012 9:27 AM
  • Just an update ... Each person with the error code has the FSP-{ temp files in their folder roots.  After deleting the FSP-{ temp files, sync restores to normal.  This can be an easy fix.  We can update the sync app to find and delete left over FSP's before running the provider's DetectChanges method.  Are there any adverse effects to the metadata in doing this?

    Really appreciate the assistance with this :)

    Friday, December 14, 2012 9:49 PM
  • are you monitoring conflicts? as I have mentioned, the presence of FSPs may indicate that the sync might be terminating prematurely...I would follow the advice of backing up the metadata when doing syncs.

    Monday, December 17, 2012 3:00 AM