The traditional use of SAVEPOINT is to save a spot "inside" a transaction. Almost all other implementations of SQL REQUIRE a transaction to already be in progress before you can create a savepoint (which makes total sense -- how can you save the state of something which does not exist?). SQLite also requires a transaction to be in progress to create a savepoint. However, when in autocommit mode (that is, you have not issued an explicit "BEGIN" statement) each statement is executed inside a magical transaction, so the SAVEPOINT statement is processed within a transaction (albeit a magical one) and it is the state of the magical transaction which is "saved".
BEGIN ... ... do some stuff .. SAVEPOINT xxxxx -- save this spot in the transaction ... do some more stuff ... ROLLBACK to xxxxx -- ooops, undo that stuff and do this instead ... alternate stuff ... COMMIT; As someone else commented, if you do not know whether or not you are inside a transaction you have much bigger, more deeply seated, issues. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
