> -----Original Message----- > From: Andrew Finkenstadt [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 21, 2007 2:56 PM > To: [email protected] > Subject: [sqlite] transaction best practices, post-committal headaches > > In my sqlite framework I have the concept of a transaction, which uses a > pair of begin transaction (immediate, exclusive, normal) / end transaction > or rollback transaction statements that execute based on C++ object > construction and stack unwinding destruction. The transaction, if it's > marked as .failed() by some sqlite::execution object, will issue the > rollback upon destruction, otherwise it'll issue the "commit" operation of > "end transaction" followed by the execution of some dummy statement. > > It's that dummy statement that I find somewhat annoying, as begin > transaction and end transaction are documented as merely setting an > autocommit flag and it's the execution of some FUTURE statement that > actually causes the commit.
What documentation do you see that makes you think that's the case? COMMIT does the commit *and* as a side-effect of ending the transaction restores auto-commit mode, so far as I know. There should be no need to execute a dummy statement. That seems to work in all of my tests. -- James ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
