Hi, Just thought I would try help,

My understand (and I not really expert like others here)
There must always be connection>>transaction>>statement(dataset)

Even if the dataset is put in local application memory it still must have a connection to DB (This to manage changes to Data) the connection must be via a transaction.. Everything you do to a DB is done via a transaction

Image you have two users wanting to add 1 to a value in the dataset..

Both open the data set around the same time and get a starting value of 10..
User A add 1 to 10, to make 11..
While later
User B also adds 1, is the result (11) or do we want the result to be (12)! The transaction manage this problem

thus if the transaction disappears or closes all the data in our dataset can't be verified we have lost track of the real data value at our start point

That is the reason why u can't change transaction once you open a dataset/statement

Hope this helps you

Richard



From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On Behalf Of masonwheeler
Sent: Tuesday, 25 September 2012 10:33 a.m.
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] How do I post multiple datasets in a single transaction?

--- In IBObjects@yahoogroups.com<mailto:IBObjects%40yahoogroups.com>, Helen Borrie <helebor@...<mailto:helebor@...>> wrote:
>
> >And if that's what you mean, I can't set up the transaction first because there are multiple different editing operations which might require saving different groups of datasets together. Besides, if I did that, it would still require assigning a transaction to the dataset
>
> That's not the way things work at all. See my previous message.
> You can have multiple transactions per connection and multiple statements per transaction. What you can't have is statements hopping about between different transactions.
>
> Do you understand transaction isolation at all?

Of course. Do you understand the concept of local, in-memory data (a dataset) at all? Because you seem to be conflating it rather seriously with the concept of updates being applied to the database.

> Statements (specifically, SELECT statements) return result sets, which you are referring to as datasets.

No, I am referring to the TDataset descendant object (TIBOTable) that holds the local data from the result set in memory as a dataset.

> By default, transactions are read-write. As soon as you "post" the outcome of an edit (UPDATE), append (INSERT) or delete operation on the client side, the record concerned becomes locked to other transactions until your transaction is committed.

So let me get this straight. Are you telling me that all client-side edits get immediately transmitted to the database, without waiting for me to call ApplyUpdates? What's the point of having an ApplyUpdates method, then? This just keeps getting crazier!

>How it is seen by other transactions after your transaction commits depends on the isolation level of those other transactions.

What are you talking about? It should not be seen by *any* transactions until I actually start to send changes back to the database.

> >, and having to close and reopen the datasets every time I change transactions is insane.
>
> Why do you think it is insane?

Why do you think it isn't? Having to pull all that data that's already in memory *back* from the database into local memory again, just because I want to start a new transaction? What's *not* insane about that? What if I had a million rows in the table?

> Do a bit of reading up about transactions? There are quite a few papers on the subject at http://www.ibobjects.com/TechInfo.html. Also check out the IBO help on the various data-access classes.

I'm quite familiar with the concept of transactions. What I'm trying to understand is how to decouple them from *local edits*.


________________________________
The information contained in this email and any accompanying files is strictly confidential and intended only for the individual or entity named above. If you are not the intended recipient of this email communication, please kindly erase it and notify the sender by reply email. Any use, dissemination, distribution or reproduction is strictly prohibited. Views expressed in this communication are those of the individual sender and may not necessarily represent the views of WizBang Technologies. No guarantee or representation is made that this communication is free of error, virus or interference.


[Non-text portions of this message have been removed]