This is happening in an Android app. No other process is involved, but the filesystem there is weird, so I'm focusing on the third possibility you mentioned.
Thanks, -- E On Mon, Sep 12, 2016 at 7:52 PM, Richard Hipp <d...@sqlite.org> wrote: > On 9/12/16, Eric Sink <e...@sourcegear.com> wrote: > > OK, this seems like a simple thing, but I'm stuck and looking for > > inspiration or clues. > > > > How can sqlite3_prepare_v2() return SQLITE_BUSY for a simple SELECT > > statement when in WAL mode? > > > > Immediately prior, a sqlite3_exec("BEGIN TRANSACTION") succeeded. > > > > The failing call is just sqlite3_prepare_v2(), and the SQL passed is > > nothing more than > > > > SELECT (explicit column list) FROM (table) WHERE (pk) = @Id > > > > So if WAL mode means writers don't block readers, it seems like > preparing a > > SELECT statement should not give me error code 5. Ever? > > Another process might have opened the same database with > locking_mode=EXCLUSIVE > (https://www.sqlite.org/pragma.html#pragma_locking_mode). If the > database is owned by Chrome or Firefox then that is likely the problem > because they both do that. > > Or, there might have been an abnormal shutdown and some other > processes has since opened the database and is now trying to recover. > Recovery is done while holding an exclusive lock. > > Or there might be some issue with your filesystem that is preventing > the processing from acquiring locks on the file. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users