Sync Events for Conflict Handling, Progress Reporting, Business Logic …


Let me just say that synchronization services eventing model is so rich. It is designed to enable you to build many of the features that business applications demand. Some of those features that come to mind are:

  • Monitoring and progress reporting
  • Conflict detection and resolution
  • Tracing and debug logging 
  • Business logic
  • Auditing
  • Schema creation tweaks

So what are those events that I am talking about? well, let me go through them here. To begin, I’d like to divide the events into two categories, provider events and agent events.

Sync Provider Events

Change Enumeration Events

  • SelectingChanges – This event is fired prior selecting changes in any of the tables in a group. The event is at group level.
  • ChangesSelected – This event is fired after the provider concludes enumeration of changes for all the tables in the group. This event is at group level.

Change Application Events

  • ApplyingChanges – This event is fired prior applying changes in any of the tables in the group. The event is at group level. You can access the changes dataset through this event and apply any kind of business logic your scenario demands.
  • ChangesAppliedEvent – This event is fired after the provider concludes application of changes for all the tables in the group. This event is at group level. The dataset of changes along with the set of conflicts encountered while applying are also available from the event arguments. This way you could log them to a file for auditing or tracing purposes.
  • ApplyChangeFailed – This event is fired when an attempt to apply a row resulted in a failure. This event is at row level.

Progress Event

  • SyncProgress – This event is fired at the table level after selecting changes from a given table. The event is also fired at the row level after applying a given row.

Schema Creation Events (Client Provider only)

  • CreatingSchema – This event is fired prior to creating table schema on the client database. This event is at the table level. The schema is represented by a DataSet object and using this event you could tweak the schema definition if needed.
  • SchemaCreated – This event is fired after creating a table on the client database. This event is at the table level. The connection and transaction objects are also available through this event so that you could execute extra commands in the same transaction. This is useful in case you want to add an index or a constraint to the table that just got created. 


Sync Agent Events

Session Events

  • SessionProgress – This event is fired in the context of Synchronize() call. It fires at pre-defined checkpoints in the synchronization process: reading metadata, creating schema, uploading changes, downloading changes and writing metadata. If you are trying to show synchronization progress bar in a form, for example, then this event is the one you would want to use.
  • SessionStateChanged – This event is fired to indicate the state of the agent session which is either ready of synchronizing. The event is fired in the context of Synchronize() call.


As you can see, you have many points to plug in your code and perform myriad of tasks while synchronization is in progress. Many of these events were driven by the experience we have working with SQL Server merge replication customers. I’d be interested to know what you think and if these events would help you building your custom logic.

One final note before I go is that not all the events listed here are available in the current beta 1 bits; few are coming up in beta 2.

 

Update: Just to let you know, I left Microsoft to start a new company, Raveable Hotel Reviews. See examples: Romantic Hotels in NYC, Best Hotels in Seattle, Top 10 Hotels in Myrtle Beach, Kid Friendly Hotels in Chicago, Hotels with in-room jacuzziand Best Hotels in Miami. Your feedback is welcome on twitter.com/raveable, raveable blog.

Comments (2)

  1. Neo says:

    Where is code, anyone can write these kind of theory, do you want me to write some?

  2. SYNC IS VERY VERY SLOW says:

    Dear All,

    SYNC IS VERY VERY SLOW (With batching) using bidirectional by terminal

    I have implemented batching from syncguru website, now it is working fine, but it takes a long time to complete the process. "Demo VIII: Offline Application – Batching"

    the link is http://www.syncguru.com/…/SyncServicesDemoBatching.aspx

    Total records in my table : 60,000 records

    BatchSize : 3000

    Total Duration : For updating 1000 records, it takes more than 90 seconds

    i need to reduce the "Total Duration" upto 30 seconds atleast.

    Please provide your valuable suggestions.

    Thanks in advance.

    regards

    yesu

    yesudassmca@gmail.com

    —  

    —  ***********************************************  

    —     NewAnchor proc with batching support  

    —  ***********************************************  

    —  

    create procedure [dbo].[sp_new_batch_anchor] (  

           @sync_last_received_anchor bigint ,  

           @sync_batch_size int,  

     @sync_max_received_anchor bigint output,  

     @sync_new_received_anchor bigint output,    

     @sync_batch_count int output)    

    as              

    if @sync_batch_size <= 0  or @sync_batch_size is null  

    set @sync_batch_size = 3000  

    if @sync_max_received_anchor is null  

        set @sync_max_received_anchor =  min_active_rowversion()-1 — @@DBTS –min_active_rowversion()-1  

    — simplest form of batching  

    if @sync_last_received_anchor is null or @sync_last_received_anchor = 0  

    begin    

        set @sync_new_received_anchor = @sync_batch_size  

     if @sync_batch_count <= 0 or @sync_batch_count is null  

      set @sync_batch_count = (@sync_max_received_anchor /  @sync_batch_size) + 1  

    end  

    else  

    begin  

        set @sync_new_received_anchor = @sync_last_received_anchor + @sync_batch_size  

     if @sync_batch_count <= 0 or @sync_batch_count is null  

      set @sync_batch_count = (@sync_max_received_anchor /  @sync_batch_size) – (@sync_new_received_anchor /  @sync_batch_size) + 1  

    end  

       — check if this is the last batch      

       if @sync_new_received_anchor >= @sync_max_received_anchor  

       begin  

           set @sync_new_received_anchor = @sync_max_received_anchor          

     if @sync_batch_count <= 0 or @sync_batch_count is null  

      set @sync_batch_count = 1  

       end