Demo IV: Offline Application – Conflict Handling
Hi all,
I just posted the forth demo in the series. This demo extends the previous demos and adds conflict handling logic. Conflicts are fact of life in occasionally connected synchronization scenarios. As a sync developer, you need to find a way to deal with this type of changes that if applied without too much thought will lead to data loss and unhappy customers. Synchronization Services for ADO.NET provides the necessary infrastructure to enable you to detect, surface and resolve conflicts. In this demo, I show you how to register to receive conflict events, dissect the information in SyncConflict object and surface it to the user, and the different options to resolve each conflict.
I encourage you to read the full description of the demo on my blog:http://blogs.msdn.com/synchronizer/archive/2007/02/07/demo-iv-offline-application-conflict-handling.aspx
To download the demo directly:http://blogs.msdn.com/synchronizer/attachment/1615465.ashx
Thanks
Interesting!
This seems to be a store feature and not sync feature. For example, your store could have a history of all changes that happen to a given row or maybe just the last change. If this is the case, then your SelectUpdatedConflictRows and SelectDeletedConflictRows commands can be written in such a way to return the current conflict row along with the available history of changes. Your conflict event handler can then use this history to decide how to resolve the conflict.
You can implement this history feature yourself using triggers for example. The point is, if you have the information, you can surface it through Sync Services APIs.
The SQLCE sync provider does not capture old changes and thus cannot surface any “before update” information.
Thanks
Hi Alekesy
The normal course of action is that I will update the row with the client change if there was no change to the row since the last time the client synchronized. This is what the where clause does, as you see below
update [orders]
set [order_date] = @order_date,
[update_originator_id] = @sync_client_id_hash
where (update_timestamp <= @sync_last_received_anchor or update_originator_id = @sync_client_id_hash) and [order_id] = @order_id
Now if this condition was not met, a conflict is detected and surfaced to the developer through the ApplyChangeFailedEvent. The runtime gives you the hooks needed to tell you what the user wants to do with this conflict. The sync runtime does not implement that logic though, for "client wins" resolution option, it just flips the @sync_forcewrite variable and pass it to your update command.
In the demo, when the force write flag is set, I just overrite the existing row. The where clause is not needed anymore.
Hi Rafiq,
I had gone through the samples you had provided, and that really helps.
But I have DB2 at server end and hence I am facing many problems, please see if you can answer my query.
"I am using DB2 on server and SQL CE on client and we are not able to perform the sync using Microsoft Synchronization Services, though the code work fine with SQL server at server end.
We had tried with OLEDB and DB2 Data provider, with OLEDB we are able to insert one row in table but all continuous insert operations are failed and no update or delete is working.
With DB2 data provider we are able to connect to database but when we are trying to provide connection to sync service provider it is throwing an exception ": Invalid connection object. Unable to create a new instance of the connection object"
Regards
Sachin
