Multiuser Updates

You may have noticed that I did not ask you to turn on support for optimistic concurrency. You are now going to go back and check this box, but before you do, let's take a moment to put optimistic concurrency in context.

As things stand, you read data from the database and into your data grid through the SqlDataSource. You have now added the ability to update (or delete) that information. Of course, more than one person may be interacting with the database at the same time (few web applications support only single-user access).

You can easily imagine that this could cause tremendous problems of data corruption. Imagine, for example, that two people download a record:

    Company: Liberty Associates, Inc. / City: Boston / Contact Name: Jesse Liberty

The first editor changes the City from Boston to New York. The second person changes the Contact Name from Jesse Liberty to Milo Liberty. Now things get interesting. The first editor writes back the data record, and the database has:

    Company: Liberty Associates, Inc. / City: New York / Contact Name: Jesse Liberty

A moment later, the second person updates the database and the database now has:

    Company: Liberty Associates, Inc. / City: Boston / Contact Name: Milo Liberty

These earlier updated values are overwritten and lost. The technical term for this is bad.

To prevent this kind of problem, you may use any of the following strategies:

Lock the records

When one user is working with a record, other users can read the records but ...

Get Programming Visual Basic 2005 now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.