>>>Another reason is to notify a user that a record they are about to update has already had its original value changed by another user. That user can be notified of the new value and given a chance to abort their change or go ahead and overwrite the other user's change.
>>
>>Hi Mark,
>>
>>I'm assuming that you're talking about optimistic buffering here. I'm having a problem devising a way to trap this using pessimistic buffering. Do you have any suggestions? I posted a question here today (or was it last night) about this (I forget the topic name).
>>
>>TIA,
>>Bonnie
>
>Yes, that applies to optimistic buffering only since pessimistic locks the record first before any edits can be made. Therefore, it would not be possible for another user to grab the record to edit. There would be no trapping involved in pessimistic buffering because a user can not obtain a lock on the record until the other user releases it. At that point, the next user can obtain the lock. As part of the locking code, the new data could be shown to that user. If you are using views, a requery() would be in order to guarantee the most recent data is being provided to the user.

Hi Mark,

Well, what my problem was, was not a locking problem, but when User1 is looking at a record, User2 meanwhile updates it, by the time User1 is ready to edit he's free to lock it, but what he sees on his screen is still prior to User2's updates. This is because I allow the user to do implicit editting, meaning I don't have an Edit button, the form goes into EditMode as soon as the user starts typing in a field. But, as I mentioned to Pascal in my post to him, I solved the problem last night by putting a timer on the form that automatically refreshes every X seconds if the form is not in EditMode. Works pretty good.

Thanks for your time,
Bonnie