On 1/15/16, Olivier Mascia <om at integral.be> wrote: > But the finalize of a > statement (using the C++ wrapper we build for our use over C SQLite API) is > currently differed until another prepare is done using the same Statement > object, or until the Statement object goes out of scope (destructor).
That's a problem. Until a prepared statement is either finalized or reset, SQLite must assume that you might call sqlite3_step() on it again. And so it has to continue holding various locks and other state that will be needed by that subsequent sqlite3_step() call. A better approach would be to invoke sqlite3_reset() as soon as you know that the prepared statement will not be stepped again. That will release locks (and other resources) and help other operations to proceed unimpeded. -- D. Richard Hipp drh at sqlite.org
