The interface only provides a way to start the transaction and end the transaction. The "ROLLBACK" will be performed if there is an error reported from the database during any part of the transaction. This doesn't give the application, through the interface, any way to roll back the transaction based on some other criteria. I say "through the interface" since the apr_dbd_query does give you a way to roll it back.
Is this adequate? Should there be an explicit function in the API for rolling back a transaction? I can see where mixing API calls and using explicit SQL commands can lead to problems. Rick Keiner --- Ronen Mizrahi <[EMAIL PROTECTED]> wrote: > Thank you for responding. > May I ask also a question about the apr_dbd > interface and how it should > be used with sqlite in order to roll back a > transaction. I was looking > for a way to rollback a transaction, and it looks > like the interface > right now allows one to start a transaction and to > commit it but it does > not allow one to roll it back. I ended up using > apr_dbd_select() with an > SQL string of "ROLLBACK", is this how the interface > intends for users to > do it? Should there perhaps be function in apr_dbd > for rollback? > > Rick Keiner wrote: > > > I have been working on that and you're right, the > "END TRANSACTION" is not > > needed and makes transactions fail. I removed it > and the test case works > > fine. I'll get a patch to the list soon. I've been > working on a seperate > > problem with the new release of SQLite that may > effect the driver. I would > > like to complete that first and then submit a > patch to the list. > > > > */Garrett Rooney <[EMAIL PROTECTED]>/* > wrote: > > > > On 9/15/05, Ronen Mizrahi wrote: > > > Yet again, I would like to ask if anyone has > any feedback on > > this? If > > > someone out there is pondering some issues > about this, please > > respond, > > > perhaps a discussion may help and at the > least I would know that > > someone > > > is planning to address this issue. > > > > I suspect nobody has gotten around to looking > at it. If you think > > there's a problem, a patch to correct it or at > least to add a test > > that shows the issue would certainly be > appreciated. As it stands, > > it'll just have to wait until someone who > understands the sqlite code > > gets some free time. > > > > -garrett > > > >
