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? Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
