--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:

> 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.

My datasets don't have a transaction assigned (property is set to nil) until this point. (See my reply on the other subthread for the reason.) And why does a transaction object care about in-memory changes in the dataset in the first place? It doesn't become relevant to the concept of transactions (a DBMS concept, not a client concept) until you actually start sending stuff back to the database. So yes, what you're describing is quite bizarre.

> I have no idea why you think DBX can overrule that. The client interface goes: connection owns transaction owns statement.

And where does the TIBOTable come in in that model?

> 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.

Yeah, except that that bears zero resemblance to what I'm actually trying to do. I have datasets representing the entire contents of a few tables, so I'm using TIBOTable. They get edited by the user, and when the user hits Save, I want to post the changes back to the database. Creating separate datasets for this would be horribly messy and get things out of sync.

> 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.

Yes, I'm aware of that. That's why I put a Commit statement at the end of the procedure.