How about always referencing all tables via attached db names? That way, "main" 
is never referenced, neither explicitly nor implicitly, and is therefore never 

-----Urspr√ľngliche Nachricht-----
Von: Stephan Beal []
Gesendet: Montag, 27. Oktober 2014 09:43
An: General Discussion of SQLite Database
Betreff: Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 9:23 AM, Hick Gunter <> wrote:

> SQLite treats each attached database as a separate entity. Attaching
> the same file twice is just asking for problems.
> 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.

That's the thing - if we leave out the explicit DB names then it works as 
expected (or against expectations, depending on one's world view). It's only 
when adding the explicit db name qualification that it locks.

i agree, attaching an opened DB is a huge kludge, but the problem is

- this app (libfossil) managed 3 different databases. Which one of those gets 
opened first is unknown/unknowable, and there is no requirement than any of 
them get opened, or maybe only a subset will. fossil(1) has the same setup but 
juggles the dbs somewhat differently and does not expose any interface to the 
outside world, so this has so far remained an "internal"
problem with no effect on clients.

- sqlite automatically names the first db "main," and provides to way to change 

- end effect is: client code must know which order the dbs were opened in order 
to know which name is correct for each logical DB. This is a painfully leaky 
abstraction, though.

- a couple months back Simon suggested ATTACHing the db to itself so that we 
can effectively alias "main" to the well-known name we have specified for that 
db instance. It worked like a charm until Dave discovered this weird locking 

----- stephan beal
"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

 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

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

Reply via email to