>>>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
>
>One possibility will be to have a collection of saved records (individual record saved with scatter name loRecord and then it's added to collection).

I think we'll do as we did in FoxPro DOS. Create a copy upon entering Form2.

Thanks all,

Alex