--- In IBObjects@y..., "Helen Borrie (TeamIBO)" <helebor@t...> wrote:

> > 2) If the user saves the changes in the inner form, then the
> >changes in LittleTrans become part of the changes in BigTrans. This
> >is because each invocation of the inner form will result in a
> >separate transaction instance. For example, the user may invoke

this

> >inner form 5 times during the lifetime of the BigTrans, and may

only

> >want to save the changes from 3 of these invocations.
> >
> > Is #2 possible?
>
> Nope. InterBase doesn't support nested transactions. The only

solution

> available to make the whole "Big Thing" rollback-able is not to

commit what

> you call the "inner transactions" but to keep everything within the

same

> transaction.
>
> IBO helps you, though. Look at the TIB_TransactionSource - you can

place

> this on your child form and, in the OnCreate, hook it up to the

transaction

> on the main form. Start a new transaction before you create the

child form

> (or before the door opens for the child form activity to begin).

On the

> child form, provide some sort of a Go/Cancel mechanism for the user

in case

> s/he changes her mind. Don't do a row-by-row commit on the child

form

> : just post the work from the child form and let the main form

take care

> of committing or rolling it back.

Thanks, Helen, but this doesn't help. The user may have made
changes using BigTrans before the LittleForm invocation and would
expect that all changes (including those in LittleForm) would be part
of the overall transaction.
The only way I could think of is to dynamically create a new
TIB_Transaction upon each LittleForm invocation. When the user
commits BigTrans, the program would go thru' the dynamically
allocated transactions and commit all of them then, and then delete
them. To the user, all changes are part of the main transaction, and
they have the ability to rollback out of each LittleForm invocation,
but its a pain-in-the-*** for me to do it.

IS there any problems with this approach?

Thanks. Eric.