What does RetryWithForceWrite really do? And what really happened when ErrorsOccured conflict is triggered? RRS feed

  • Question

  • Hi all,

    I am interested to know when ApplyAction.RetryWithForceWrite executed, is it an Update SQL call is done to the database, Or an Insert SQL call is done to the db?

    While I was synchronizing a local SQLExpress table with a SQLServer2008 server table, it took a very long time to process. Eventually I found out that ApplyChangeFailed event was triggered and a LocalUpdateAndRemoteUpdate conflict was detected. What I did to handle this case was to apply ApplyAction.RetryWithForceWrite. Because this is a download only sync, so I always wanted the copy in the server to overwrite that in local.

    After little debugging I found that my program was stuck at the ApplyChangesFailed portion. What happened was although ApplyAction.RetryWithForceWrite was successfully executed, the row and the row in tracking table were not updated, causing the ApplyChangeFailed event to trigger again and again and my program ran into a "infinity loop".

    The reason why LocalUpdateAndRemoteUpdate happened although my program never update the localserver is because my localserver is set to sync with 2 servers, one test server and one production server, so in testing mode the localserver will be synced to test server or otherwise. But the data in both the test and production for that table is the exactly the same. I am guessing the LocalUpdateAndRemoteUpdate conflict was raised because of the difference timestamp in tracking table etc...

    Anyway, I was expecting the row to be updated so that the timestamp is the same and ApplyChangeFailed will not happen in the next sync but it never happened.. and my program went into infinity loop..

    I also synced a table for the first time with the server. It triggered an ErrorsOccured conflict, which I have no idea why it happened... I solved the issue by deprovisioning the server and provision again.. any clue?

    Thanks in advance!

    Wednesday, December 5, 2012 11:09 AM