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. In the framework I use I do not need to worry about other sqlite select statements still being in execution, so I worry-not about the warnings on this page: http://www.sqlite.org/lang_transaction.html . This is approximately what executes: void impl::begin_transaction() { int nrows = m_db.get_connection().execDML("begin immediate transaction;"); ++nrows; // don't care what its value is } void impl::commit_work() { int nrows = m_db.get_connection().execDML("commit transaction;"); // turn auto-commit back on nrows = m_db.get_connection().execQueryScalar("select count(0) from dual;"); // and do it. silly SQLITE3 ++nrows; // don't care what its value is } Is there a recommendation on what statement to execute after committing the transaction? --andy
