Indices, foreign keys, ... all work only within a single DB file, so allowing a qualifier would suggest functionality that is not present and probably quite hard to provide.
How would one keep an index residing in one DB file consistent with a table in a different file if only one of the files is attached? In these cases, the qualification is implied. NB: IIRC this also applies to views, but seems not to be prominently documented. Eg. CREATE INDEX db.index_name ON [=>db.]table_name ... CREATE TABLE db.table_name (...) FOREIGN KEY (...) REFERENCES [=>db.]referenced_table CREATE TRIGGER db.trigger_name ... ON [=>db.]table_name ... CREATE VIEW db.view_name AS SELECT ... FROM [=>db.]table_name ... -----Ursprüngliche Nachricht----- Von: Stephan Beal [mailto:sgb...@googlemail.com] Gesendet: Montag, 27. Oktober 2014 20:18 An: General Discussion of SQLite Database Betreff: Re: [sqlite] quasi-bug related to locking, and attached databases.... On Mon, Oct 27, 2014 at 11:59 AM, Stephan Beal <sgb...@googlemail.com> wrote: > On Mon, Oct 27, 2014 at 11:53 AM, Hick Gunter <h...@scigames.at> wrote: > >> TEMP tables get created in database temp; which is located in "a >> file" or "in memory" depending on the SQLITE_TEMP_STORE preprocessor >> symbol and the pragma temp_store. >> > > Which reveals my ignorance on the topic ;). IIRC we aren't using a > specific temp store - we're using whatever's compiled in by default. > > So... maybe paying for a :memory: handle we "don't really use" won't > be as painful as i first thought. Just add a pragma call to ensure > that we're using disk instead of memory for temp store. > Follow-up: injecting a :memory: db as the first-opened DB turned out to be a very small change (because the code was set up for that at one point), and it turns out that using ATTACH for all three of our library-level DBs gives us three or four minor features/benefits we didn't have before. e.g. it was impossible to close one of the three DBs in one particular (and as yet hypothetical) use case, but we can now attach/detach each one at will without regard for the others or which one was opened first (as that role is now taken by the :memory: placeholder). All in all, making that change was a win. Sidebar: it turns out there are some contexts where fossil does not allow db.table qualification (namely (REFERENCES D.T) and (CREATE INDEX ... ON D.T(F)) do not allow it), but that's a topic for another thread if/when it becomes problematic (so far it's only a hypothetical problem, and not one worth losing any sleep over). @Gunter: Vielen Dank for clarifying where TEMP tables go: that misunderstanding was why i migrated away from this setup in the first place. (Und schoenen Gruss aus Muenchen!) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: h...@scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
