>>The client wishes to use pessimistic buffering. A first for me as I'm used to optimistic. Anyway, I need the best method for determining when a record is locked by another user. I can see in the "find" method and checking when retrieved from disk, great, set all the controls to read only. As I understand pessimistic locking, the lock does not take effect until "EDITING" has happened. This tells me that 2 different users could retrieve the same record; user 1 retrieves, user 2 retrieves before user 1 has started editing and a lock is obtained. (Maybe user 1 got up and went somewhere) So now I've got two users with what appears to be valid records prepared for editing except that neither is yet locked. (User 1 comes back) User 1 presses a key and gets a lock, what's the best way to check for the lock to let user 2 that someone beat them to it? User 2 thinks they've got an unlocked record and suddenly it blows up.
>>
>>Steve
>Steve,
>
>An ON ERROR trap that handles the Record Is In Use error that occurs when user 2 tries to edit.
>
>BTW, are you aware that you can provide a pessimistic approach to contention management with optimisitic buffering?

Jim,

Now there's a concept...a pessimistic approach to contention with optimistic buffering". Could you elaborate a little? And thanks for the info on ON ERROR.
That's what I'll try today.

Steve