Simon Slavin wrote: > On 1 Jan 2014, at 7:43am, Alexander Syvak <alexander....@gmail.com> wrote: > >> The code in function from the 1st e-mail is used before exiting, so the >> sqlite3_close is called in fact. > > Please do not cross-post between sqlite-dev@ and sqlite@. If you need to > move from one to the other, start a new thread. > > I can't find the post that started the thread but if you're having trouble > using sqlite3_close() then the database is probably not being closed. > Please check the result returned and log an error if it's not SQLITE_OK so > you can be sure whether it worked or not. > > If _close() really isn't working for you it's probably because you have an > unfinalized statement. This can happen if sqlite3_finalize() fails (though > it really shouldn't) So check and log the result code from sqlite3_finalize() > too. > >>> while ( (rc = sqlite3_close(db)) == SQLITE_BUSY) > > > I'm not happy about this. SQLITE_BUSY should not be a reason to start > running other statements. It should be a reason to back off and announce > failure to the user. To avoid getting _BUSY and then having to write a > handler yourself set a good timeout (ten seconds ?) using > > sqlite3_busy_timeout()
Waiting for timeout *cannot* fix any errors that can trigger failure in sqlite3_close. Those are *program logic* errors. > after the database is opened. From then on you can treat SQLITE_BUSY the > same as other failure results. But you *cannot*. Sure, there are cases when longer timeout can help. But not in all. Even with larger timeout, SQLITE_BUSY often requires some or other special handling (ROLLBACK transaction *and retry* in case of step()/exec(), detect unfinished statements in case of close(), etc). (Sometimes you can avoid some special cases by using BEGIN IMMEDIATE, close_v2(), etc appropriately). _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
