I personally always use a Timestamp column and an identity Column on every table i design and use the "First change win" approach, i program system that are accessed by hundreds of users simultanously, and i find this approach to be to most effective.

In the updates, the where clause is also much more compact ie: Where Identity_column = ? and TimeStamp = ?

If the update fails i warn the user of the failure. And ask them to refresh the data and try again.

This is the most restrictive approach but you gain:
1- Small update queries
2- Faster updates, the server only compares 2 fields.
3- Much safer then letting the user decide to override someone else changes.
4- If the DB and the system is well designed, the conflicts will not happend very ofter.

What if the change was made by a posting program? Would you let a user overwrite it ?


>>This is greate Bonnie BUT,
>>what if the same column updated from defferant users??, here is the problem.<
>
>How likely is that to happen? If it's something that happens only occasionally, I'd say it's no big deal, but if it's something that happens frequently in your particular application, then I think the way that I would handle it is to warn the user that this has happened and ask them if they still want to save (perhaps the warning message could also contain the user name of the person who made the change first so that current user can ask the other person about who's information is more up-to-date). Typically, this kind of decision is part of designing the application requirements and I have no idea what your requirements are.
>
>~~Bonnie