> Yes. That's precisely the intended use case. Remember though that the > transaction is not really committed until COMMIT statement runs: if your > application crashes or machine loses power, all changes to the beginning of > the transaction are rolled back, not just those since last "committed" > checkpoint.
Does my memory fool me or there are some error conditions in SQLite when it automatically (without explicit user request) rollbacks the whole transaction disregarding any savepoints? If it's indeed the case then OP should handle these situations in his class (if they are possible in his SQLite usage pattern). Pavel On Wed, Nov 3, 2010 at 2:02 PM, Igor Tandetnik <[email protected]> wrote: > jeff archer <[email protected]> wrote: >> I am using SQLite from C++ and I have implemented a class to manager nested >> transactions using savepoints. I have currently implemented as a stack of >> transactions such that the first Begin uses BEGIN IMMEDIATE, while subsequent >> levels use SAVEPOINT Tnnnn where nnnn is a sequentially increasing number >> starting at 0001. Commit does RELEASE on the latest SAVEPOINT or a real >> COMMIT >> once savepoint stack is cleared. Rollback does ROLLBACK TO or a real ROLLBACK >> once savepoint stack is cleared. >> >> Is this OK to mix savepoints with transactions like this? > > Yes. That's precisely the intended use case. Remember though that the > transaction is not really committed until COMMIT statement runs: if your > application crashes or machine loses power, all changes to the beginning of > the transaction are rolled back, not just those since last "committed" > checkpoint. > -- > Igor Tandetnik > > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
