At 09:20 AM 25/09/2012, you wrote:

>If I was using DBX, and I wanted to ensure that changes from multiple datasets were committed in a single transaction, it would go like this:
>
>tran := connection.BeginTransaction;
>try
> dataset1.ApplyUpdates;
> dataset2.ApplyUpdates;
> connection.CommitFreeAndNil(tran);
>except
> connection.RollbackFreeAndNil(tran);
>end;
>
>IBO doesn't seem to work that way. And in fact, as I've just discovered, it doesn't seem to work *at all* when trying to post multiple datasets in one transaction.
>
>Here's what I'm trying, using datasets of type TIBOTable:
>
> tran := TIB_Transaction.Create(nil);
> try
> try
> tran.IB_Connection := connection;
> tran.StartTransaction;
> dataset1.IB_Transaction := tran;
> dataset2.IB_Transaction := tran;
> dataset1.ApplyUpdates();
> dataset2.ApplyUpdates();
> tran.Commit;
> except
> tran.Rollback;
> raise;
> end;
> finally
> tran.Free;
> end;
>
>The problem with this is that, for some bizarre reason, assigning the transaction object to the dataset SILENTLY CLOSES THE DATASET, which causes all the changes that I'm trying to commit to be lost!
>
>What in the world is going on here, and how do I get this to work properly?

It's not "bizarre" at all. It's not (and never has been) possible to pick up pending work from one transaction (the one that owns your datasets) and post them in another. I have no idea why you think DBX can overrule that. The client interface goes: connection owns transaction owns statement.

If you want to have a discrete transaction to perform only this operation then create the transaction, then create the queries (as many as you want), do the work, then post the datasets. Note that, unless you are using an autocommit transaction, Post writes a pending change to disk, that is not visible to other transactions. Unless the transaction is committed, that work will remain pending until hours after the user has gone away - at which point, the engine will mop up and roll back that transaction.

Helen