On Thu, Sep 24, 2015 at 4:56 AM, ALBERT Aur?lien < aurelien.albert at alyotech.fr> wrote:
> @ Stephan Beal > > "Every instance of a :memory: db is a unique instance, so you cannot have > multiple connections to a single :memory: db." > > >> I know, this is one of the various reasons that made my solution not > really ideal > > @ Simon Slavin You can share in-memory databases using URI names. https://www.sqlite.org/inmemorydb.html "There's a PRAGMA for storing and retrieving a 'user-version' in the > database: > > <https://www.sqlite.org/pragma.html#pragma_schema_version> > > It's not used by SQLite itself, you can use it to store any 32-bit signed > integer. So you could store a different number to each of your databases > and check to see whether the user-version of one connection is the same as > that from a different connection." > > >> That's a good idea, but this 'user-version' pragma is persistent and > stored on disk. So it's difficult to use in my case : if the user quit the > application and restart it without loading the same databases (or in the > same order) assigning 'user-version' id will be really difficult. > I'm not exactly sure what your concern is. If you assign it a random number, each database will still see a different value next time you open things, regardless of ordering. If you're greatly concerned about birthday paradox, you could do something like: CREATE VIEW IF NOT EXISTS GUID AS SELECT '<generated GUID>'; and then use that to differentiate databases. In fact, I expected something like a unique memory address (void*) per > database. For the most part they're entirely distinct connections each accessing the same underlying file, there's no reason to have such a unique memory address. You may be able to do something using shared-cache mode: https://www.sqlite.org/sharedcache.html I can't immediately tell if this would mean a single underlying handle to the file or not. If so, you could maybe use sqlite3_file_control() to dig into things. But shared-cache mode changes how things work a bit, so it might not be appropriate for this use case. -scott