April 17, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Handling Data Conflicts in the Microsoft Sync Framework, Page 4

  • April 23, 2009
  • By Matt Goebel, Rachel Baker
  • Send Email »
  • More Articles »
If we choose Continue, we get another ClientInsertServerInsert conflict, this time on the client SyncProvider:



Click here for larger image

Listing 1.8 ClientInsertServerInsert conflict on the client

If we choose Continue again, you can see that the changes were not applied to either database. Each database keeps its changes and essentially ignores the conflict.



Click here for larger image

Listing 1.9 ClientInsertServerInsert conflict on the server and client with ApplyAction.Continue

As in the previous example, if we choose RetryApplyingRow, we will continue to get the conflict dialog.

If we choose RetryWithForceWrite, we are not presented with the client SyncProvider conflict (the conflict has already been resolved) and the client changes will be uploaded, overwriting the server changes:



Click here for larger image

Listing 1.10 ClientInsertServerInsert conflict on the server with ApplyAction.RetryWithForceWrite

Resolving Client Conflicts with the ConflictResolver

If handling conflicts with specific resolution schemes isn't required and you want to minimize the amount of code you write, MSF offers one additional property on the SqlCeClientSyncProvider to make your life a bit easier. The ConflictResolver property can be set to individually handle all five conflict types with three options.

  • ClientWins
  • ServerWins
  • FireEvent

The final option, FireEvent, is the default for each conflict type and will fire the ApplyChangeFailed event discussed in the previous section.

The code for setting up ConflictResolver can be added to the client SyncProvider's constructor (you can find it in the code of the .designer.cs code file) along with the ApplyChangeFailed handler if needed:

this.ConflictResolver.ClientDeleteServerUpdateAction = 
 Microsoft.Synchronization.Data.ResolveAction.ServerWins;
this.ConflictResolver.ClientUpdateServerDeleteAction = 
 Microsoft.Synchronization.Data.ResolveAction.ClientWins;
this.ConflictResolver.ClientInsertServerInsertAction = 
 Microsoft.Synchronization.Data.ResolveAction.FireEvent;
this.ConflictResolver.ClientUpdateServerUpdateAction = 
        Microsoft.Synchronization.Data.ResolveAction.FireEvent;
  
this.ApplyChangeFailed +=new 
 System.EventHandler<MICROSOFT.SYNCHRONIZATION.DATA.APPLYCHANGEFAILEDEVENTARGS>
 (DataConflictsDataCacheClientSyncProvider_ApplyChangeFailed);

In the above example, we always allow updates to win over deletes, and we let update conflicts be resolved through custom business logic to be defined in the handler for the ApplyChangeFailed event.

Conclusion

All data synchronization solutions will require some form of data conflict resolution. With the Microsoft Sync Framework, there is a built-in conflict resolution mechanism that allows you to define a conflict resolution scheme that is as simple (ConflictResolver) or as involved (custom business logic resolution through the ApplyChangeFailed event) as you need it to be to fit your application.

About the Authors

Matt Goebel is a manager with Crowe Horwath LLP in the Indianapolis, Indiana, office. He can be reached at 317.208.2555 or matt.goebel@crowehorwath.com.

Rachel Baker is a senior developer with Crowe Horwath LLP in the Oak Brook, Illinois, office. She can be reached at 630.990.4434 or rachel.baker@crowehorwath.com.





Page 4 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel