I guess I'm not sure what you are expecting to find. The Where clause approach
described is one way of checking whether data has been changed by another user
before performing an update. Any approach to managing multi-user concurrency is
going to be along these lines, whether it uses timestamps, or a test of all data
columns, or some other mechanism. The only other option is to lock records at
the time they are retrieved, which is generally not a good idea.

If there are several tables involved in an update, the update can be wrapped in
a transaction, and you can add code to rollback the entire transaction if any of
the individual rows are not updated successfully. I'm not sure if you will find
a complete example of that anywhere, but you should be able to find examples of
using a transaction.

John,

As you have a concurrency violation (you can see that with a standard
dataadapter update on the returned errorstate of a datarow), then you have
some possibilites, however the first one is to show it to the user.

And then you can tell him to do it over again after you have got the new
values from the database.

You can show the new values and ask if it should be replaced by the just
typed ones and do that like this.

However all is up to you, don't think that this will happen often,
concurrency errors should be in most situations rare.

Cor