> On Feb 6, 2018, at 4:13 PM, Simon Slavin <[email protected]> wrote: > > Before you call sqlite3_close_v2(), do this: > <https://sqlite.org/capi3ref.html#sqlite3_next_stmt > <https://sqlite.org/capi3ref.html#sqlite3_next_stmt>> > and deal with any problems.
Actually, I already do that, to log info about the open statements (see my earlier email today.) But that doesn't directly help. This shows me the sqlite3_stmt pointers, but not the C++ objects of mine that own them. I'd need to find those and null out the statement pointers in them, which means I'd need a data structure that maps from a sqlite3_stmt to my object. This is basically the option (a) I sketched out. There's the additional problem that sometimes there are open statements that don't belong to me, like the one in my earlier email that belongs to the FTS4 extension. My current plan is to call sqlite3_close() first, then if it fails with SQLITE_BUSY I will call sqlite3_db_config() to enable SQLITE_DBCONFIG_NO_CKPT_ON_CLOSE, and then call sqlite3_close_v2(). From my reading of sqlite3PagerClose() and sqlite3WalClose(), that config flag should prevent the WAL from being deleted when the zombie db closes. —Jens _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
