When you are working with the Sync Framework (a topic of a coming soon post), you will inevitably run into issues related to data modified both on the client and the server, more clearly: update conflicts. There are five types of update conflicts, defined in the ConflictType enumeration:
- ClientInsertServerInsert: both the client and the server insert a row with the same primary key.
- ClientUpdateServerUpdate: the client and server changes the same row (this is the most common conflict type).
- ClientUpdateServerDelete: the client updates a row, which have been deleted on the server earlier.
- ClientDeleteServerUpdate: the client deletes a row, which have been updated on the server.
- ErrorsOccurred: an error prevents the change from being applied.
To detect errors during synchronization, you should use the ApplyChangeFailed event of your provider class. This returns an ApplyChangeFailedEventArgs object, which exposes information about the rows in conflict, the error, and lets you specify the Action to take. The Action can be a member of the ApplyAction enumeration, which defines the following set of them:
- Continue: continues the synchronization, and adds the row caused the conflict to the Conflict class exposed by the ApplyChangeFailedEventArgs object.
- RetryApplyRow: retries applying the row one more time.
- RetryNextSync: only in P2P, stores the row, and then tries to apply it in the next synchronization process.
- RetryWithForceWrite: read MSDN, I don’t understand the topic clearly.
You have one last powerful ally when you are dealing with conflicts. It’s called SyncConflictResolver, and you exposes some properties to deal with the cases defined in the ConflictType enumeration. These properties can take a value from the ResolveAction enumeration, which has the following members: ClientWins, ServerWins and FireEvent. FireEvent fires the above mentioned ApplyChangeFailed event.
For more detailed information, you should refer to MSDN. Sadly, the content about update conflict is very spare in the Training Kit, so you should read MSDN thoroughly even if you have it.