Hi Eric,
Thanks for the suggestion, but the reason that I use pessimistic buffering is to avoid all that conflict-handling stuff. Otherwise, I would use optimistic buffering. < g > As you can see from my other posts, I resolved the issue by auto-refreshing the form. Works for me!

Bonnie

>You could use buffered edits and TABLEUPDATE(), without the lForce parameter. Also, in VFP6 look at the conflict catcher class in FFC.
>
>>Sylvain,
>>Nope, not gonna work. I've tried several variations on this theme and tried placing code in several different methods (When, InteractiveChange), but nothing seems to trap it accurately.
>>
>>HELP! There's gotta be a way to do this! It's not a complicated task. Any other suggestions????
>>
>>Bonnie
>>
>>>How about a loop that goes through each control and compare the current value of the control to the value in the ControlSource? Something like (haven't tested it):
>>>
>>>

llDirty = .F.
>>>
>>>FOR EACH Controls IN THISFORM.Controls
>>>   IF Controls.Value <> (Controls.ControlSource)
>>>      llDirty = .T.
>>>      EXIT
>>>   ENDIF
>>>ENDFOR
>>>
>>>IF llDirty
>>>   *-- Record was modified. Maybe advise the user before doing a Refresh()
>>>ELSE
>>>   *-- Everything OK, start the edit mode
>>>ENDIF

>>>HTH
>>>
>>>>I know it might be confusing, that is why I was looking for some way to detect that the record had been changed so that I could notify the user of that prior to doing a refresh(). Any other ideas on how to trap for this?