Yep OK. I stand corrected. BTW thanks for your help.
-----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Igor Tandetnik Sent: October-30-13 12:16 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Problem with SQLITE_BUSY The documentation for BEGIN TRANSACTION (http://www.sqlite.org/lang_transaction.html) does: An implicit transaction (a transaction that is started automatically, not a transaction started by BEGIN) is committed automatically when the last active statement finishes. A statement finishes when its prepared statement is reset or finalized. The explicit COMMIT command runs immediately, even if there are pending SELECT statements. However, if there are pending write operations, the COMMIT command will fail with an error code SQLITE_BUSY. The ROLLBACK will fail with an error code SQLITE_BUSY if there are any pending queries. Both read-only and read/write queries will cause a ROLLBACK to fail. A ROLLBACK must fail if there are pending read operations (unlike COMMIT which can succeed) because bad things will happen if the in-memory image of the database is changed out from under an active query. Igor Tandetnik On 10/30/2013 12:09 PM, Normand Mongeau wrote: > Then IMO the documentation for either sqlite3_prepare_xx or > SQLITE_BUSY should state this. It would have been helpful in my case, > I was pulling my hair looking at the transaction model which was sound. > > > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin > Sent: October-30-13 12:07 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Problem with SQLITE_BUSY > > > On 30 Oct 2013, at 4:03pm, Normand Mongeau <nmong...@theobjects.com> wrote: > >> Well finally found the problem: a forgotten sqlite3_finalize() call. >> >> Very disturbing, I'd expect leakage, not the results I was seeing. > > SQLite has to keep the state of your SELECT available until you tell > it you're done with that SELECT. After all, you might look at the > results you have retrieved and decide to make some changes based on what you see there. > This means SQLite has to stop everything from changing the database. > Therefore it locks it. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
