>>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.