Manage update conflicts between online and offline data

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:

Monitor event notifications

There might be times when you’d wish to receive a notification about a change in the returned results of a command. In these times, you would use the SqlDependency class, living in System.Data.SqlClient. For it to work, you should enable SQL Service Broker for your database, because raising notifications requires you to do so.

As I stated, SqlDependency can be used to query whether or not a given SqlCommand’s result changed (or any related changes have occurred in the database, such as a failure). There are two ways to get notified about changes: query the HasChanges property of the current SqlDependency instance, which is a Boolean value informing you about changes in the database. The other, more robust approach is to use the OnChange event of it. It returns an instance of SqlNotificationEventArgs, which exposes the following properties:

• Info: gets the reason of the notification.
• Source: gets the source of the notification.
• Type: the SqlNotificationType of the notification. Can be Change, Subscribe or Unknown.

Now that you know the basics, here’s an example:

Cache data

In this post, we’ll examine two ways of how to cache data in a .NET Framework application. For ASP.NET web apps, we’ll use SqlCacheDependency, and for desktop applications, we’ll consider using the Local Data Cache.

When dealing with ASP.NET applications, you have multiple choices to cache data, by using one of the state management techniques (I have written multiple posts about them, so search for them), but for now, we’ll consider using the Cache class. Before you’d write any data caching code, you should start in the web.config, as usual. Take a look at the following block:

<system.web>
<caching>
<sqlCacheDependency pollTime=”1000” enabled=”true”>
<databases>
<add connectionStringName=”aString” name=”databasename”/>
</databases>
</caching>
</system.web>

After this, you should place something similar to your data access class: