It all depends on the size of the application, if it's possible the database be hit by a large amount of users, record locking is not recommended. Record locking is something from the past and to my knowlegde is rarely used today.

But as Bonnie said, it all depends on your buisiness requirements, there is more than one valid ways of doing things.

Stephane

>Warning the user of the failure and asking him to refresh, will make the user mad if a lot of typing is involved!
>
>I was thinking of building a way something like this (depending on record lock, but Bonnie does not recommend this way!):
>
>When 1st user open the record, data will be displayed as view only in the form, then if he desided to update some data he should click "Modify" button, when he clicks it, the system will lock the record till he saves the data.
>
>Now, when another user try to modify the same record, a worning message will appear saying this record is being updated and will stay in view mode till the first user relase the record.
>
>Record lock will stop user conflicts.
>
>
>
>>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