Warren Young writes: >> Note that SQLite isn't really designed for concurrent access >> to the database file from a different process. > > There is a paucity of truth in that statement.
So let me re-formulate that sentence: concurrent access ultimately relies on the file locking provided by the OS. The concurrency support in SQLite is simply to not keep state outside a critical section and lock the database file exclusively when entering one. > But, there's only so much SQLite can do to cooperate with the OS's > locking strategy. On POSIX systems where SQLite was born, locking is > mostly advisory and cooperative, whereas Windows gives you mandatory > locks by default in a lot of cases. Mandatory locks allow one process > (e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to > change a file, indefinitely. Cygwin should (and apparently does) abstract away that difference. But it seems that the locking strategy might be slightly different between Win32 and POSIX, triggering a foray into that "disk I/O error" branch. There may still be a bug some place else, i.e. it may get a timeout rather than a "file locked" state. I'll have a look when I find some time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
