Absolutly, user2 would get an update conflict and his transaction would be rolled-back.

Like i said, this approach is the most restrictive for concurency. I always program this way, even for small apps, i have seen too many small apps become very large OLTP over time.

But if the DB is well designed, lets say a customer table containing the name, address and basic info. and other related tables such as AR due amounts, transaction table etc. The update conflicts are unlikely to happend.

But this just my preference, other techniques are also good but over time and experience, i found the "first change wins" technique worked better for me.

Stephane

>Wouldn't this approach report an update conflict when there wasn't one?
>
>User1 opens record for editing
>User2 opens record for editing
>User1 edits field1 only and saves
>User2 edits field2 only and saves
>An update error is reported.
>
>
>>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