>>>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.
>>
>>This seems a very valuable reason to do the checking. I always use pessimistic buffering, so I don't have the problem, but the solution you propose is nicer, and I will definitely try it out !

>Wait a minute, Pascal. You're using pessimistic buffering but you're not >having a problem with determining changes made by another user? What are you >doing that I'm not? My problem arises when User1 is viewing a record, User2 >then makes and saves a change to the same record, User1 then decides to edit >the record, but his form is still showing the record as it was before User2 >saved his change. How can you trap for this?

Bonnie,
you're pointing out a problem here that I wasn't aware of ; I think that as in my programs the user explicitally has to indicate he wants to start modifying I didn't have to handle this problem (I thought the screen did some kind of autorefresh as exist with browses in FP DOS).
I'll check it out and keep you informed ...

>Hope you have some suggestions. I've tried everything I can think of (and some >pretty kludgy stuff).

Sorry, but I've only started programming in VFP for some months, so I've still a lot to learn, but thanks to this UT it goes pretty fast ...