What is Compared Exactly to determine if Source fields are synched to a peer-to-peer Destination? RRS feed

  • Question

  • I posted a prior question regarding this issue, but wanted to try and query for help alternately asking my question in the most basic form -

    Does anyone know *exactly* how the sync orchestrator determines what records from the Source peer's SelectIncrementalChanges command are to be inserted/updated on the Destination peer?


    I'm hoping someone can answer this question without using an example that utilizes timestamps. I am looking to do a sync that detects differences based on different row versions rather than time differences, so I'm looking for help on a very basic level as to how it it determined within a CUSTOM DbSyncProvider whether to apply inserts and/or updates from a Source peer provider.

    I assume that since I am writing the custom SQL and/or stored procs and binding the SQL to my own custom providers/adapters, that I should be able to easily accomplish this. But it just doesn't seem to work fort a very basic app that I put together.


    Can someone in the know please provide some insights as to how the sync process determines which records to sunc with the Destination simply by discussing the inputs and result sets of the custom adapter commands?






    Monday, June 14, 2010 10:36 PM

All replies

  • Timestamp is not really datetime. It's a number to track what has changed for the rows. It allows you to select the changes since last sync with the other DB Sync Provider. When you give these enumerated changes to Sync Framework, Sync Framework will actually determine whether these changes are already known by the other DB sync provider and if that's the case, will not send the already-known rows to the other DB, otherwise, it will call insert/update/delete command to the other DB sync provider.

    Tuesday, June 15, 2010 6:40 PM
  • I'm not sure you read me quation clearly ... I said that I am looking to do a sync that detects differences based on different row versions rather than time differences, tiemstamps or otherwise.

    I'm looking for help that can make me understand better how to write the commands for my custom adapter based on a version - in my case I will be using a Uniqueidentifier as a version id for each row. I want to simple compare versions to decide if a row gets added or updated.

    In a test app, I set up, I used a tracking table with the version for each row. This version info gets stored by the meta data during a sync operation. The triggers on the base table set the version to NULL. When a successive sync occurs, I update any rows on the destination peer that have version data in the tracking table that differs from the rows and version I am pushing out to the peers.

    I have it working mostly except that I can't seem to get new rows inserted in my source to be synched to my peer. A record appears in the destination peer tracking table with tombstome=1 and the new record is not inserted in the base table. I can't figure out why. I am using the same SQL/stored procs geneerated from the SqlSyncProvider simple provider demo, and I just added the additional logic to compare versions.

    My plan is to eventually remove the timestamp logic completely after I see that my new login comparing versions is working. Will that be possible? For instance, the SelectIncrementalChanges command that's generated from the sample app, returns:

    , [side].[sync_row_is_tombstone]

    , [side].[local_update_peer_timestamp] as sync_row_timestamp

    , case when ([side].[update_scope_local_id] is null or [side].[update_scope_local_id] <> @sync_scope_local_id)
      then COALESCE([side].[restore_timestamp], [side].[local_update_peer_timestamp])
      else [side].[scope_update_peer_timestamp]
      end as sync_update_peer_timestamp
    , case when ([side].[update_scope_local_id] is null or [side].[update_scope_local_id] <> @sync_scope_local_id)
        case when ([side].[local_update_peer_key] > @sync_scope_restore_count)
        then @sync_scope_restore_count
        else [side].[local_update_peer_key]
      else [side].[scope_update_peer_key]
      end as sync_update_peer_key
    , case when ([side].[create_scope_local_id] is null or [side].[create_scope_local_id] <> @sync_scope_local_id)
      then [side].[local_create_peer_timestamp]
      else [side].[scope_create_peer_timestamp]
      end as sync_create_peer_timestamp
    , case when ([side].[create_scope_local_id] is null or [side].[create_scope_local_id] <> @sync_scope_local_id)
        case when ([side].[local_create_peer_key] > @sync_scope_restore_count)
        then @sync_scope_restore_count
        else [side].[local_create_peer_key]
      else [side].[scope_create_peer_key]
      end as sync_create_peer_key


    If I remove these from my result set, will my sync still work if I am basing my change detection on other criteria altogether? I'm hoping that the internals of the sync orchestrator aren't tied toneeding and using these fields to work; if you can provide any insights to that, it would be extremely helpful.







    Wednesday, June 16, 2010 1:04 AM
  • Using Guid is not supported with DB sync provider. DB Sync provider requires the sync app to keep track of local store changes using a increasing tickcount kind of metadata so that incremental changes can be selected from the local data store. The type of column we have tested is timestamp. With Guid, that's not possible.

    Is there any reason you could not use timestamp for the Db Sync provider in the database?

    Friday, June 18, 2010 12:29 AM