...and after the lock remember to recheck if editing is still legal (for your app) if the fields have changed.

>I don't use pessimistic locking myself, but I think a solution would be to add an edit button (I assume that you are starting the edit mode as the user type something right now) to the form. In the Click() event, obtain a Lock() and issue a Refresh() if successful.
>
>HTH
>
>>This question is going to sound really stupid, but I'm stuck.
>>
>>I'm using Pessimistic Row Buffering.
>>
>>User1 is viewing a form (no changes yet).
>>
>>User2 edits (and saves) the same record that User1 is looking at.
>>
>>User1 decides to start editting the record (but what she sees is what the record was prior to User2 editting it, because of buffering). As soon as she starts entering a change, the status bar at the bottom of the screen says that "Record has changed".
>>
>>How do I trap for this and notify User1 that the record has been changed?
>>
>>I thought of using CURVAL() and OLDVAL(), but the docs say that they will only show correct results (ie, different) if you are using optimistic bufferring.
>>
>>I have an ON ERROR routine set to trap for not obtaining the record lock when the user starts editting, but this particular scenario does not apparently generate an error.
>>
>>What am I doing wrong? Or should I say, what am I not doing right?