locked
DbOutdatedSyncException RRS feed

  • Question

  • First I think it is important to note that we are synchronizing on a worker thread ... and bubbling exceptions up to the UI thread.

     

    This happens very rarely (1 out of 500 syncs) ... but as best I can tell this is what is happening.

    While in .Synchronize(), the JIT reports an error with its "Continue?" prompt and of course users are selecting to continue - the sync black box then continues syncing the same sync.

    On a subsequent sync a DbOutdatedSyncException exception is thrown ... any thoughts on how we can trap this or at least stop the sync from continuing while in .Synchronize()?

     

    Also, now that the sdf can't sync without throwing an exception (at this point we have to create a new sdf) here is what is peculiar ... we put the UI call to the .Synchronize() method in a try/catch with a catch for DbOutdatedSyncException ... the error during sync is not caught by the catch!

     

    Is it possible to recover from outdated sync knowledge without creating a new sdf?

    What specifically would throw the DbOutdatedSyncException ... batch files that got delted without being applied or sync knowledge that was cleaned up on the client prematurely?

     

     

    Monday, January 30, 2012 7:08 PM

Answers

  • check out the SyncPeerOutdated event, you can set it to do PartialSync or AbortSync
    • Marked as answer by P H T Wednesday, February 1, 2012 1:30 PM
    Tuesday, January 31, 2012 9:44 AM
  • I ran into this issue when I was too eagerly cleaning metadata, fixed it by not cleaning metadata....

    to get the needed data up without wiping the data I set PartialSync as JuneT has referred.

    • Edited by Racing_Prog Tuesday, January 31, 2012 8:25 PM
    • Marked as answer by P H T Wednesday, February 1, 2012 1:30 PM
    Tuesday, January 31, 2012 8:13 PM

All replies

  • check out the SyncPeerOutdated event, you can set it to do PartialSync or AbortSync
    • Marked as answer by P H T Wednesday, February 1, 2012 1:30 PM
    Tuesday, January 31, 2012 9:44 AM
  • will look at that ... thanks.

    since writing my original questions I have more information since i had one more occurrence last night.  A sync successfully completed ... then the user sync'd again within 30 minutes and that sync failed due to the DbOutdatedSyncException.

    any thoughts on what would cause the DbOutdatedSyncException exception and also how to recover from it w/o creating a new sdf?


    • Edited by P H T Tuesday, January 31, 2012 2:24 PM
    Tuesday, January 31, 2012 2:18 PM
  • I ran into this issue when I was too eagerly cleaning metadata, fixed it by not cleaning metadata....

    to get the needed data up without wiping the data I set PartialSync as JuneT has referred.

    • Edited by Racing_Prog Tuesday, January 31, 2012 8:25 PM
    • Marked as answer by P H T Wednesday, February 1, 2012 1:30 PM
    Tuesday, January 31, 2012 8:13 PM
  • are you doing a metadata cleanup every sync?
    Tuesday, January 31, 2012 10:51 PM
  • early on I was as aggressive as Racing_Prog above ... now I am performing a cleanup every sync with the retention days set to the number of days since last successful sync + 1 ... so I keep at least one extra day of metadata.  I am going to release a new version that does not perform a cleanup to see if the issue goes away ... but I think my business rules look solid based on log files which record activity/parameters.

    New information:

    Adding this event handler allowed the sync to continue despite the outdated sync knowledge:

    void ceProvider_SyncPeerOutdated(object sender, DbOutdatedEventArgs e)

    { e.Action = DbOutdatedSyncAction.PartialSync; }

    Any thoughts on what might cause the sync knowledge to become outdated (especially important as we never had this before and recently we are getting it more often).

    Also, what did SF actually do when it ran this code ... did it fix bad sync knowledge (subsequent syncs go through w/o the same issue) ... is it possible some records did not get sync'd?

    Wednesday, February 1, 2012 1:22 PM