Handling Data Concurrency Using ADO.NET

      One of the key features of the ADO.NET DataSet is that it can be a self-contained and disconnected data store. It can contain the schema and data from several rowsets in DataTable objects as well as information about how to relate the DataTable objects—all in memory. The DataSet neither knows nor cares where the data came from, nor does it need a link to an underlying data source. Because it is data source agnostic you can pass the DataSet around networks or even serialize it to XML and pass it across the Internet without losing any of its features. However, in a disconnected model, concurrency obviously becomes a much bigger problem than it is in a connected model.

       In this column, I'll explore how ADO.NET is equipped to detect and handle concurrency violations. I'll begin by discussing scenarios in which concurrency violations can occur using the ADO.NET disconnected model. Then I will walk through an ASP.NET application that handles concurrency violations by giving the user the choice to overwrite the changes or to refresh the out-of-sync data and begin editing again. Because part of managing an optimistic concurrency model can involve keeping a timestamp (rowversion) or another type of flag that indicates when a row was last updated, I will show how to implement this type of flag and how to maintain its value after each database update.

Part 1 http://msdn.microsoft.com/en-us/magazine/cc163924.aspx

 

      Enterprise development has been moving towards a discon-nected model in recent years and ADO.NET development is no exception. While the disconnected model of the ADO.NET DataSet offers great flexibility, that adaptability also means looser control over data updates than you get with a connected data access model. One related issue is data concurrency. This month I'll focus on concurrency violations that occur when multiple rows could be saved to the database in a single batch.

      When a concurrency violation occurs, the SqlDataAdapter's ContinueUpdateOnError property tells the SqlDataAdapter to either throw an exception or ignore the concurrency violation. I will demonstrate how to show exactly why a concurrency violation occurred by setting the ContinueUpdateOnError property to true and using a series of DataViews bound to ASP.NET DataGrid objects. These DataGrids will use the DataViewRowState enumerators to show what changes have been made to a DataSet.

      The SqlDataAdapter also has some events, including RowUpdating and RowUpdated, which can come in handy. To illustrate their use, I will also show how to deal with concurrency by creating a handler for the RowUpdated event.

      In last month's Data Points column, I discussed how to deal with concurrency violations and ran through an example of a violation that occurred when only a single row was updated at a time (see Data Points: Handling Data Concurrency Using ADO.NET). In that situation, setting the SqlDataAdapter's ContinueUpdateOnError property to false told the SqlDataAdapter to throw an exception as soon as a concurrency violation was encountered. This technique is ideal when only saving a single row or when you are attempting to save multiple rows and want them all to commit or fail. However, if you want to save the rows that do not encounter concurrency violations and display the rows that do cause concurrency violations, you must use another technique.

Part 2 http://msdn.microsoft.com/en-us/magazine/cc163908.aspx