On a Mac running OS X 10.6.8 Server. Being accessed by another Mac running 10.6.8 Client.
The shell tool I'm using is the one found on a standard installation of OS X 10.6.8. It accesses the database by opening the file across an AFP connection to the server. The shell tool can read and write the database file itself fine. The app which is meant to access this database is an Apache/PHP app. It uses the SQLite3:: object-oriented API to access the database. For necessary reasons the PHP app opens the database twice: once with SQLITE_OPEN_READONLY, reads stuff, then closes it, then opens again with SQLITE_OPEN_READWRITE, reads and/or writes stuff, then closes it. All this happens very fast, with no pauses for user-input or long processing by anything apart from the SQLite engine. When either the shell tool or the PHP app are used by themselves they work fine, but I used the SQLite shell tool for monitoring something and while that tool had the database open my PHP application got errors SQLite3::query(): Unable to execute statement: database is locked in [...]readrec.php So my question is ... while the shell tool has a database open across an AFP connection, do I expect it to prevent PHP from accessing the database ? Or is perhaps the PHP language giving the wrong error at the wrong time, opening the database as READONLY when I asked for READWRITE because it couldn't get READWRITE ? I looked at the source code for the shell tool. I'm not good at C, but as far as I can tell it opens the database file in a sharable manner, not in a way as to lock it against other apps. I tested this by using two copies of the shell tool at the same time and the work just fine, both able to have the database open at the same time and see each-other's changes. So that doesn't seem to be the problem. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
