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
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to