none
Infinite Loop issue RRS feed

  • Question

  • Hi All,

    I hope some can shed a bit of light here. I have a situation where we have SQLExpress on the local machine and SQLServer2008 on the server. We have sync set up and it was running perfectly and filtering the data correctly. We then discovered that the data we had been given to work with originally was incorrect. Some of our primary keys were incorrect. I should probably specify that the primary key is a compound key of a date field and a facilityID and some of the facilityID's had been set incorrectly. We used an SQLScript to update the ID's  some of the facility ID's were swapped with other and some were just changed to new values (basically deleting the old ID). The problem is now when we try to sync we are getting an error on these lines.

     

    void SyncRemoteProvider_RemoteApplyChangeFailed(object sender, DbApplyChangeFailedEventArgs e)

            {           

                    if (e.Conflict.Type != DbConflictType.ErrorsOccurred)

                    {

                        e.Action = ApplyAction.RetryWithForceWrite;

                    }      

            }

     

     

    The DbConflictType which is actually occurring is a LocalUpdateRemoteDelete error. The row this is happening on is in the tracking table. The thing is the row in the table that this tracking row refers to doesn't exist any more (thanks to our ID change). On both the local and server database this row does not exist but the entry still exists in both tracking tables. Here is where i'm unsure about things. Shouldn't the tracking table pick up that the row it refers to was deleted and just ignore it? How does a tracking table actually say "There was an update here", "There was a delete here" Which field on a tracking table holds this info? Another thing I spotted was that it is the local provider that is showing that there are changes pending so why is the RemoteApplyChangeFailed event the one that is causing the errors? 

    I'm sure there is probably an easy fix here of just running the script that we used to change the ID's in the tables, on the tracking tables as well. But I want to actually know why this is happening instead of just covering it up. One last thing we want the client machine to win out on any conflicts so the code above is correct isn't it? 

    Any info anyone can provide will be appreciated.

    Regards,

    David

     

    Friday, November 11, 2011 7:18 PM

Answers

  • what error are you getting?

    the tracking table entries for deleted rows will remain in the tracking tables unless you do a metadata cleanup. these rows are the ones with sync_row_is_tombstone set in the tracking table. if you're sure these rows are non-existent and just leftovers of the PK updates you did, you can run a metadata cleanup to remove these rows

    when you did the pk updates, did you just update on one side and let sync framework cascade the change or did you update the PKs on both side then did a sync?

    what's your sync direction? assuming you have bidirectional or upload scenario, if the changes are detected in the local provider, then the apply is done on the remote provider, so the applychangefailed will be on the remote provider since its the one applying the changes.

    if the above code for conflict handling is on the remote provider, then you have configured the client to win on conflicts.

    Friday, November 11, 2011 10:48 PM
    Moderator
  • Hi June,

    Sorry for the late reply. Thanks for the advice it did point us in the right direction. Just to clarify for anyone who might be experiencing similar issues the sync direction was bi-directional and the error we were getting was a dbConflictType.LocalUpdateRemoteDelete. As you can see from the code above this error was not being handled so the code above kept trying to RetryWithForceWrite and kept filing causing the application to simply hang. We tried clearing the metadata cleanup like suggested (which i didn't realise you could do) but it didn't delete the rows from the tracking table which were causing the issues.

    To fix the issue we had to specify that on a dbConflictType.LocalUpdateRemoteDelete the ApplyAction was set to continue. After running one sync with this we then ran the metadata cleanup and it worked. Something in the tracking tables must have been flagging these rows as valid before the sync and only after the sync they were marked as eligable for deletion by the metadata cleanup. With that everything was sorted.

    Thanks again for the help JuneT

    Regards,

    David

    Tuesday, November 15, 2011 12:10 PM

All replies

  • what error are you getting?

    the tracking table entries for deleted rows will remain in the tracking tables unless you do a metadata cleanup. these rows are the ones with sync_row_is_tombstone set in the tracking table. if you're sure these rows are non-existent and just leftovers of the PK updates you did, you can run a metadata cleanup to remove these rows

    when you did the pk updates, did you just update on one side and let sync framework cascade the change or did you update the PKs on both side then did a sync?

    what's your sync direction? assuming you have bidirectional or upload scenario, if the changes are detected in the local provider, then the apply is done on the remote provider, so the applychangefailed will be on the remote provider since its the one applying the changes.

    if the above code for conflict handling is on the remote provider, then you have configured the client to win on conflicts.

    Friday, November 11, 2011 10:48 PM
    Moderator
  • Hi June,

    Sorry for the late reply. Thanks for the advice it did point us in the right direction. Just to clarify for anyone who might be experiencing similar issues the sync direction was bi-directional and the error we were getting was a dbConflictType.LocalUpdateRemoteDelete. As you can see from the code above this error was not being handled so the code above kept trying to RetryWithForceWrite and kept filing causing the application to simply hang. We tried clearing the metadata cleanup like suggested (which i didn't realise you could do) but it didn't delete the rows from the tracking table which were causing the issues.

    To fix the issue we had to specify that on a dbConflictType.LocalUpdateRemoteDelete the ApplyAction was set to continue. After running one sync with this we then ran the metadata cleanup and it worked. Something in the tracking tables must have been flagging these rows as valid before the sync and only after the sync they were marked as eligable for deletion by the metadata cleanup. With that everything was sorted.

    Thanks again for the help JuneT

    Regards,

    David

    Tuesday, November 15, 2011 12:10 PM