Garrett ---

I agree with Jim. You can use RLOCK() as a check at start of edit and just leave the lock until end of edit, with pessimistic buffering as is. Another way would be to create a syslocks table and create a flag record holding record key and user when a record is being edited and release the flag record when user is done like the way SBT Accounting used to do eons ago (semaphore locking? Is that the correct phrase?).


>I think you don't have much chioce but to use RLOCK().
>
>As I see it, the buffering schemes only move the problem - they don't change the real issue in any way.
>
>So you can RLOCK() at start of things, stopping them from getting any further, *or* you can write the code to try to do the users a favour (since you let them get all the way to the end, not very nice to now wipe out what they have done).
>
>That's my opinion
>
>Cheers,
>Jim N
>
>>I have a form that I want to prevent multi-user editing on. I turned pessimistic buffering on and changed the global error handler to throw up a message whenever error 109 came up.
>>
>>Works fine. If I open it twice, and make an edit to the record in one instance, I get the messagebox in the other instance.
>>
>>HOWEVER....
>>
>>If I save the changes in the first instance, and then save the (unmade) changes in the second instance, the second one overwrites the first one. What's the easiest way to deal with this? If I had the time and budget, I'd make it truly multi-user, with CURVAL() and OLDVAL() checking each field, but that isn't really an option.
>>
>>My next choice is RLOCKing the record when I go into edit mode, but I'd rather work with buffering and implicit locking....