Richard, Simon, > Le 15 janv. 2016 ? 16:30, Richard Hipp <drh at sqlite.org> a ?crit : > >> 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.
I think this is well understood now. Thanks Richard. > 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. > Le 15 janv. 2016 ? 16:31, Simon Slavin <slavins at bigfraud.org> a ?crit : > > Immediately after doing your first _step() you should be thinking to do your > _finalize() or _reset() as soon as practical. It should weigh on your mind > like an open door in a high-crime area. Having done either of those, you can > keep the statement around as long as you like: all it will use up is a little > memory. Thanks Richard and Simon. We indeed need to design the Statement class differently to sqlite3_reset() it as soon as possible. And I now realize that I overlooked one detail, which will help a lot. For select-kind queries I can capitalize on sqlite3_step() having to be called until it returns SQLITE_DONE (so one more time than there are rows). When that happens, I can sqlite3_reset() immediately. The programmer has been done with the previous (last row) since before the last call to step(). Same thing for SQLITE_OK, which would be returned for successful non-row returning queries, it can call reset() right away. I'm only left with the case of a row returning query which the programmer would not want to step() up to the end. In this case, it is very reasonable to have the programmer think of "freeing" the query in some way through either the Statement class going out of scope or the call of some "reset()" method. You see, the whole purpose of using a thin set of classes over the C API is to make it as easy as possible to merge SQL statements within the C++ code of the application. I have done this exercise for some other databases, but I'm new at SQLite. Again thank you very much for the very valuable input this mailing list provides. When we will be code-complete and able to decide for SQLite in our next releases, we will happily contract one of the paid professional support options HWACI offers. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om
