On 15 Jan 2016, at 3:18pm, Olivier Mascia <om at integral.be> wrote:
> Be sure I'm not reusing any statement handle without finalizing it. No > leaks, we have a checker in place to detect. 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). We might have to > add a method to 'clear' our Statement objects as soon as not needed anymore. > Though that probably is not very important in our real programming, the > configuration I had in the test which returned LOCKED on the wal_checkpoint > is 'synthetic' and not really representative. A Statement is generally > re-used for successive different queries while a method is doing whatever its > job is, then the local Statement goes out of scope (so its last instance gets > finalized). Please don't do this. Until you have done your _finalize() or _reset() that statement can be taking up a lot of memory and/or have temporary files created and/or have locks on files. You want to release all this stuff as soon as possible to prevent your program from being a memory/disk/resource/handle hog. Remember that the only reason _prepare, _step, _finalize/_reset are not all one command is that not all operating systems allow SQLite to callback your program to tell it that the next row is ready. 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. Simon.
