On May 18, 2010, at 10:18 AM, Sam Carleton wrote: > For those of you following along my life (which I hope none of you > are), I > am working on cleaning up my code to handle SQLITE_BUSY correctly. > The > first issue I think I just successfully overcame was how to lock the > DB to > get my code to return a SQLITE_BUSY. What I did was use the > Firebird plugin > to start an exlusive transation, then call a function that does a > straight > foward query: > > 1. Open DB as read-only > 2. prepare statement: > SELECT FolderId, ImageId, sortTime > FROM V_FAVORITES_SELECTED > WHERE sortTime > julianday(@time) LIMIT 1 > 3. bind the one parameter > 4. call step > > I was expecting the step to return SQLITE_BUSY and according to the > documentation, I can retry that because this is a read-only query. > But low > and behold, the sqlite3_prepare_v2 returned SQLITE_BUSY. Per what > others > have suggested on this mailing list, I looked at the documentation of > sqlite3_prepare_v2 to see if I could retry the prepare statement. > It is not > discussed. > > Q1: In the above situation, can it retry the sqlite3_step a few times? > > Q2: What are the correct ways to handle sqlite3_prepare_v2 returning > SQLITE_BUSY?
Just retry it. The SQLITE_BUSY occurred because SQLite tried to read the database schema (a read-only transaction within sqlite3_prepare(), with all the locks that requires). If you had a busy-handler installed it should be invoked in this scenario. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
