locked
Sync collaboration setting in sync services 2.0 and circular updates RRS feed

  • Question

  • I have a database that has some fairly large tables; biggest one is around 4 million records.  I am trying to sync the whole database when I do syncs down to a local server and then back up to my network server.  When I first provision a database for syncing and then do my first sync down to my local server I get some 400,000 changes being sent down, which is fine, I expect that.  However, if I change something minutely on the local server (so a mininum amount of records are being change, in the order of 100 or less across all tables), and then sync back up to network server, I get about the same 400,000 changes being applied to the network server.  It seems that the changes that were sent down are being sent back up on the subsequent upload.  Is there something I'm missing here?  It shouldn't send back up the records that i just downloaded, only the ones I changed locally.  Could someone explain to me how sync services 2.0 decides which records to send to the destination server?  I am I missing a setting to prevent this.  Or did I provision the servers incorrectly?  Thanks in advance.

    Monday, May 17, 2010 4:02 PM

Answers

  • Hi,

    For collaboration providers in Sync Framework, row changes of each data table are logged in its tracking table. If you have a data table TableA, its tracking table is TableA_tracking. You can find this tracking table after provisioning. Are you using the SqlSyncProvider or DbSyncProvider? If it is SqlSyncProvider, the SQL commands are auto-generated during provision. For DbSyncProvider, you need to check if the scope_info table update SQL command is correct.

    Also, if you use different sync scopes for each sync, the behavior that you saw is expected because sync changes in scope1 will be treated as local changes in scope2. Please enable Sync tracing with verbose level to find more details: http://msdn.microsoft.com/en-us/library/cc807160.aspx. If you still cannot figure out the root cause, please share the tracing logs to us.

    Thanks,
    Dong


    This posting is provided AS IS with no warranties, and confers no rights.
    Monday, May 17, 2010 6:41 PM