On Mon, Oct 27, 2014 at 3:23 AM, Hick Gunter <h...@scigames.at> wrote: > SQLite treats each attached database as a separate entity. Attaching the same > file twice is just asking for problems.
Well, it could do something to detect duplicates, but it may not be easy (or even possible) to portably detect that two DB files are the same file. The same is true for the application, of course, but it seems reasonable [to me anyways] to put this burden on the application. Still, I can see how it could be useful for SQLite3 to detect dup DB ATTACHes. Suppose you had a two-DB application, but since there's no schema conflicts you later decide that it'd be easier (e.g., easier to backup, sync, manage) to merge the two DBs into one. But you still have older code that wants two DBs... > The query specifies that the destination db be locked for write and the > source db for read; which translates to two locks that cannot coexist on one > underlying db file. And two journals, and so on. Nico -- _______________________________________________ sqlite-users mailing list firstname.lastname@example.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users