Hi Hilmar

>>What is the best practise for resolving conflict at runtime?
>>
>>Regds
>>Shaishav
>>>>Viv,
>>>>
>>>>I donot allow other person to change a record while it is being used by someone. I lock that record programatically!
>>>
>>>That is the traditional way of doing things (the only safe way to work in FoxPro 2.x). While you can still use rlock(), many developers nowadays rely on buffering, instead. With optimistic buffering, VFP will check whether another user has changed the record; with the "standard" options for TableUpdate(), the record will not be saved in this case.
>
>Assuming optimistic buffering:
>
>First of all, if you don't rlock() explicitly, there can only be conflicts if two users edit the same record at the same time.
>
>If TableUpdate() fails, you check the reason with the aerror() command. If the cause of the problem is that another user made changes, the safest route is to inform the user about this, and undo the change with TableRevert().
>
>You could also let the user decide whether he wants to save the changes anyway (see the parameters for TableUpdate()), but this is risky, IMO.
>
>To avoid too much waste of time for the users, try to keep pending changes only to one record at a time. That is, if a user changes to another record, force him to save or undo the current record first.
>
>Under these circumstances, it is actually not very common for two users to edit the same record at the same time.

Only if the data is normalized. If I make a table which contains patient information and treatments, the secretary may try to update the patient information at the same time as the doctor records a treatment.