Friday, May 06, 2005

Resolving DataSet Conflicts


The new ADO.NET DataSet object, introduced in the first release of the .NET Framework, provides a large array of options for working with data in a disconnected state. It supports being bound to user interface (UI) objects, such as the data grid. It supports marshaling by value across the network wire. It even supports working with the data offline until changes can be sent back up to the data source. It is this specific offline usage that can lead to problems.

By disconnecting the data from a live database connection, you can increase application scalability and flexibility. For example, you can connect to your corporate network using dial-up, download some data into a dataset, and then disconnect and keep working. Later, you reconnect and update the database with your changes. But what happens if another user makes changes to the same record you're working on? More importantly, what should happen?

This sample application provides one possible solution to this problem. As with any complex problem, there is no single answer that fits every application. In fact, this example is arbitrarily focused on one particular type of solution. As you will see, there are many decisions you'll need to make to find out the best course of action for your particular situation. This sample should provide a starting point to help you create the right solution for your application.
Post a Comment