Consider the following operations (full test program attached):
stmt <- prepare conn "SELECT * FROM foo"
Row <- step stmt
exec conn "BEGIN; ROLLBACK"
Row <- step stmt
Namely, we prepare a statement with sqlite3_prepare_v2, call
sqlite3_step (giving us SQLITE_ROW). While the statement is busy, we
jump in and do this:
rc = sqlite3_exec(conn, "BEGIN; ROLLBACK", NULL, NULL, NULL);
On SQLite 3.6.22, this sqlite3_exec call returns SQLITE_BUSY, and the
subsequent sqlite3_step returns SQLITE_ROW.
On SQLite 3.7.13, this sqlite3_exec call returns SQLITE_OK, but the
subsequent sqlite3_step returns SQLITE_ABORT.
The latter result looks bogus to me.
#define SQLITE_ABORT 4 /* Callback routine requested an abort */
We're not doing anything with a callback routine. And according to
the documentation for ROLLBACK:
The ROLLBACK will fail with an error code SQLITE_BUSY if there are
any pending queries.
Does this include queries started before the transaction begin? Should it?
When the sequence above is performed, I would expect one of two
results (preferably the first):
* The exec "BEGIN; ROLLBACK" has no effect on the prepared statement
that has already started.
* The ROLLBACK fails with SQLITE_BUSY (the 3.6.22 behavior).
The 3.7.13 behavior definitely looks wrong. Is this a bug, or is it
undefined behavior to BEGIN or ROLLBACK while a prepared statement is
running on the same connection?
Thanks,
-Joey
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
