none
Sync 2.1 framework conflicts RRS feed

  • Question

  • We are using sync frame work to sync multiple site to central server. everything was working very well until the system producing the data was upgraded. now in some site i get insert errors, some about FK constraints and some about normal inserts trying to insert Nulls to non null-able columns. from what i could find the _selectchanges SP is returning some non existing rows or with invalid data which then causes the errors in bulkinsert SP. DBs schema is the same as before, only data is being changed.

    A workaround is to re-provision the scope and re-sync all data this straightens things out.

    I'm trying to find the root cause so i can handle it re-syncing all data is not very good solution for us and not always possible.

    Any thoughts or ideas?

    DBs schema is the same as before, only data is being changed.

     

    Also at:

    http://stackoverflow.com/questions/7384767/sync-2-1-framework-conflicts

    Monday, September 12, 2011 9:10 AM

Answers

  • Bulkinserts by default dont fire triggers. If the triggers are not fired, the entries in the _tracking table are not created/updated and the base table and _tracking table are no longer in sync.
    • Marked as answer by kulight Tuesday, September 13, 2011 8:46 AM
    Tuesday, September 13, 2011 6:53 AM
    Moderator

All replies

  • when you say "the system producing the data was upgraded", what kind of changes were made to the database? were bulk operations (bulk insert, bcp, truncate) done on the database?
    Monday, September 12, 2011 10:19 AM
    Moderator
  • The operations are:

    1. Reading old data (to memory and file as backup)

    2. Delete the data that was read

    3. BulkInsert the modified data

     

    Tuesday, September 13, 2011 6:29 AM
  • Bulkinserts by default dont fire triggers. If the triggers are not fired, the entries in the _tracking table are not created/updated and the base table and _tracking table are no longer in sync.
    • Marked as answer by kulight Tuesday, September 13, 2011 8:46 AM
    Tuesday, September 13, 2011 6:53 AM
    Moderator
  • thank you

    I suspected it was something like this.

    I guess no way around it except rebuilding the tracking tables?

    Tuesday, September 13, 2011 7:35 AM
  • not sure how you're doing the bulk inserts but have a look at how to enable the triggers during bulk operations here: http://msdn.microsoft.com/en-us/library/ms187640.aspx

     

    Tuesday, September 13, 2011 7:41 AM
    Moderator
  • the bulk inserts are done by someone else in a different system. so its mostly out of my hands.

    any way you were very helpfull

    Thank you

    Tuesday, September 13, 2011 8:36 AM
  • Is it possible to rebuild the _tracking tables on both server and client without resorting to a complete full resyncronization?

    Ive tried deprovisioning both rebulding _tracking but  the i get errors because the data is already in the DB.

     

    is there any other way except deleting all the data in base tables while deleting the _tracking tables?

    Sunday, September 18, 2011 10:16 AM
  • the tracking tables contains information on what has been added/updated/deleted when and by whom. the actual information on what was synched is actually in the sync knowledge stored in the scope_info table.

    if you have data on both ends already, even if you reprovision both databases, you will still get conflicts as each replica has no knowledge of the data contained in the other replica. so the client will try to send all of its records which may already be existing in the server and the server will do the same on download.

    you should only have a problem on first sync, just handle the conflicts in the ApplyChangesFailed to set which record should win.

    Tuesday, September 20, 2011 2:12 AM
    Moderator
  • You are right about your analysis, but, the client win goes into infinite loop because the selectchanges SP makes up rows that have nulls in non null-able there for cannot be inserted.

    we have decided for now to do a full reset provision and full sync when needed.

    Tuesday, September 20, 2011 7:28 AM