Thanks Hilmar,

I am using two tables, say, tblOrders and tblOrderItems. tblOrders is having one-to-may relationship with tblOrderItems.

While working on Order application, user may change more than one record from tblOrderItems.

I use optimistic table buffering for both the tables, I guess thats OK?

I can't save tblOrderItems table till user presses save button to save Order. And I dont want other users to access these data while one user is amending the Order.

Please help!!

Regards
Shaishav


>>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.