Ghost entries, and unnecessary deletions, confusing tracking table entries RRS feed

  • Question

  • I am having some problems with the sync framework that have been quite annoying for the last little while. Besides these issues, sync framework has worked very well and we've had no problems with it.

    1) There are ghost entries. There are some ghost entries on the server that are always being pushed onto the client. I have looked through and pinpointed these problems to being rogue entries in the tracking table. Basically, they are all null except local_update_peer_timestamp, which seems to have binary data, last_change_datetime which is from a few months back, and local_create_peer_timestamp. These entries aren't being cleaned up by metadata cleanup also, even when I set the retention to not include the last_change_datetime. There are other entries that are the same except are also null for last_change_datetime, and these seem to be benign. It's only the entries that are null but have a last_change_datetime that the provider tries to sync(and fails, and has failed for these entries with a constraint error for the past couple months). How did these get there and what is the best practice for preventing them and getting rid of them should there be more.

    2) Which field does the SqlSyncStoreMetadataCleanup key off of? It doesn't seem to be last_change_datetime. If it's the local_update_peer_timestamp, is there a class the encapsulates the binary data in the field? 

    3) We have a tool the removes a ton of rows, and inserts a number of rows quite often. After doing this a couple times, it seems that the sync framework starts trying to delete from the destination store entries that don't exist. This seems to happen when we create entries in the local store and then delete them, only syncing after deleting. There would be no problem with this, but it compromises the bulk insert/delete, and starts slowly failing one by one. This can be quite a headache because inserting/deleting 10's of thousands of rows is not uncommon. 

    The entries beginning with 1623b4c5 and 6c7ad039 in the id field seem to be a problem.


    Thursday, February 24, 2011 6:12 PM


  • Then you do DML with bulk insert/delete, triggers dont fire by default and that is essential for Sync framework to track the changes.

    If that has happenedn, then it is quite possible that there is some inconsistency in your case.

    This posting is provided AS IS with no warranties, and confers no rights
    Wednesday, March 2, 2011 8:43 PM