I personally would see value in supporting quasi-nested transactions where they are nested in name only--increment decrement a counter and commit on last commit, rollback entire transaction on first rollback. This would have the advantage that the library would support issuing multiple BEGIN TRANSACTION statements without error.
I often find in my code that I have library routines that want to run in a transaction and can run in their own transaction or join an existing transaction. In SQLite I would need to have extra logic in place to detect the transaction state and only run in a transaction if one is not already in place. I say "would" because the SQLite.NET [1] wrapper provides nested transactions as a counter already, on top of the SQLite library (as long as I use the connection.BeginTransaction() method and don't issue an explicit BEGIN TRANSACTION call myself). Best regards, Sam [1] SQLite.NET Wrapper: http://sqlite.phxsoftware.com/ ------------------------------------------- We're Hiring! Seeking a passionate developer to join our team building products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
