Thanks for your input, Dave. And I'll keep your suggestions in mind. However, one of the main reasons that I use pessimistic buffering is so that I don't have to worry about this sort of "collision". Anyway, an auto-refresh of the form every X seconds/minutes solves the initial problem, so I think I'm ok with it now. Thanks for your time!!!!!

Bonnie


>I'm coming in in the middle of this so excuse me if I re-iterate something that somebody else mention. I normally use optimistic table buffering myself, but this algorithm should still work:
>
>1) Issue a TABLEUPDATE with the force updates parameter set to FALSE. This will cause the TABLEUPDATE function to return true if another user has changed the record since you started editing it.
>2) Once tested for a failed TABLEUPDATE, use AERROR to get the error message.
>3) Check the first element of the array returned by AERROR for error code 1585. This indicates an update conflict.
>4) from here you have several choice:
> a) issue an error message to the user and make the user get out of the record and then go back in.
> b) issue a TABLREVERT on the current users changes and then requery the record. This will make the user start editing all over again
> c) Save the current user changes to an array, cursor, properties on the data-entry controls, etc. Issue a TABLEREVERT on the current user's buffer, requery for the record and then compare values to see what was changed while the user was editing and only make the user re-enter data on the fields that are different.
>
>I hope this helps.
>
>
>Dave
>
>>Hi Sylvain,
>>
>>A good suggestion, but I like the functionality of an implicit edit, as soon as the user types something. I do have a method that's called from each object's InteractiveChange that enables/disables the Save/Cancel buttons and I could probably just do Refresh() from there. In fact, I was thinking along those lines last night, but got bogged down with the CURVAL()/OLDVAL() issue and forgot where I was initially going with the whole process. I'll try the refresh() at that point and see if that works.
>>
>>Thanks for getting me back on track!
>>Bonnie
>>
>>>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?