>>>>All tables use table buffering. I did not mention that as user edits in form2, related records in other tables are changed and sometimes even other records in main table are affected because of crazy labor rules. For this reason I need to go back to the original question of how to do transactions within a transaction.
>>>>
>>>>In an older and related application designed during FoxPro DOS days we made a copy of memory variables and of some tables upon entering form2 an then restored them if user backed out, but I don;t want to do it that way in the new application.
>>>>
>>>>Thanks for the help,
>>>>
>>>>Alex
>>>
>>>You can do nested transactions.
>>
>>Thanks Naomi.
>>
>>Would you suggest starting a new transaction as soon as entering form2 which is commited or rolled back according to user response?
>
>Alejandro,
>
>No, it doesn't make sense to open a new transaction upon entering a form if this form allows user's input. Transactions should be as short as possible,

What is the best approach?

1) In form 1, user chooses to modify monday's data and enters form2.
2) In form2 user makes changes and exits by choosing OK, not cancel.
3) He is back to form 1 and the buffered tables contain the changes made.in step 2
4) Now he choses to modify tuesday's data and again enters form2
5) In form2 he makes changes which are stored in the same buffered tables as previous data, perhaps overwriting some of the changes made in step 2. This time he chooses to exit by canceling the changes he just made. Fields need to be restored to the values established in step 2, not to the original values before step 1.

The recommendation you gave me, that transactions should be brief to minimize conflict with other users, makes sense. But other than manually saving the values as we did in FoxPro DOS the only way I can imagine to accomplish what we need is to start a transaction when entering form2.

What is the best approach? Should I bite the bullet and manually save the data?

Thank you very much,

Alex