The method doesn't allow for two users to edit the same record at the same time. Fine in smaller systems, but in larger systems with many users, in some circumstances, that isn't acceptable. Users should be able to make changes to different fields. Your *Call code to edit record....what happens if that person take a 30 minute phone call in the middle of that edit? Or goes to lunch? What happens if the 'other' person's changes need to be done immediately. For example, in my industry, if there is a lock on a record in a .dbf because someone is on the phone in the middle of an edit, and there is a field that needs to be changed by another user to allow a person to use his pay direct drug card...and that person is at the pharmacy RIGHT NOW and wants to get his prescription RIGHT NOW. And if the field isn't changed, the pay direct drug card will not work. Not very good customer service, wouldn't you agree? You can tell users "Don't do that, make the edit and get out.", but how can this be enforced.

As long as the changes don't conflict (ex. a contact person's name change and a change of address), then they should be allowed.

Of course, your method works in some cases...but I believe it is flawed in some cases.



>>Not the best method in a mulit-user environment, though. You must agree there are problems with this method.
>>
>>Joseph
>>
>>> Hi guys, even that I use "Buffering", what
>>>I do is lock the record before letting the user to make
>>> any changes, like in the old days:
>>>
>>>IF RLOCK()
>>>* Call code to edit record
>>> =TABLEUPDATE(.t.)
>>> UNLOCK
>>>ELSE
>>> *=messagebox("Record is in use by another, try later.")
>>>ENDIF
>
>Hi Joseph,
>Can you be more specific ?, which problems ?, how do you guaranteed
>that two persons don't change a record at the same time without
>locking the record ?