I'm testing a database having this configuration in a unit test framework I have, and I'm finding that when I re-run the unit test, the data in the in-memory DB seems to still be around from the previous unit test run. This sort of makes sense; the underlying idea here is something else in the same process can (re)-open the database via the same URI.
My questions are:
(a) Is this right? A shared-cache, in-memory database is "persistent" across connections from the same process that do not overlap in time?
(b) Is there some way to reliably blow away one of these databases so I know there will be no hangover state after that operation and can start fresh with a virgin database?
Calling sqlite3_shutdown() will release all the resources SQLite uses.
Technically, we’re all meant to be calling sqlite3_initialize() and sqlite3_shutdown(). In practise, nobody does because if you forget to initialize the other routines will do it for you, and quitting the process will release everything.
> ... when I re-run the unit test, the data in the in-memory DB seems
> to still be around
> Is there some way to reliably blow away one of these databases so I
> know there will be no hangover state after that operation and can
> start fresh with a virgin database?
Tell your unit test framework to blow away the connection(s).