>I have a design problem...
>
>Form1 uses View1 and calls Form2 which uses View2. Field values in View2 are used to update some fields in View1. The problem comes into play when changes have been made to View1, Form2 is called, changes are made to View2, control is returned to Form1 and the user wants to cancel changes that were originally made to View1 on Form1. The business rules dictate that the changed field values made to View2 on Form2 still need to be made to View1, but that any changes made on Form1 to View1 should be disregarded. If a TableUpdate is issued anywhere along the line then all changes will be committed. The client also insists that Form2/View2 must be called from Form1. Just can't seem to get my mind around what needs to be done here... Any ideas? Thanks!
>
>Regards, Renoir
Perhaps you need transactions. This allows you to undo changes, in several tables, even after a TableUpdate(). See the help under:
BEGIN TRANSACTION
END TRANSACTION
ROLLBACK
Please note that: a) All tables that participate in a transaction are to be part of a database. b) All changes made after BEGIN TRANSACTION are automatically locked. Therefore: keep your transaction short (in time).
HTH, Hilmar.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)