On 07 Feb 2014 at 23:04, Simon Slavin <slav...@bigfraud.org> wrote: > You should not be manually setting any handle to null. Try calling > ->finalize() on the statement and eventually ->close() on the database, which > do more than just setting their value. If you are setting anything to null > manually, this may be causing the problem you report.
I made myself a simple testbed in PHP based on the code I posted last time. I used a sleep call to make each turn round the while loop take a couple of seconds, so the code took 20 secs to complete. In another Terminal window, I ran a second script that tried to update the same database (with a 2000msec timeout). Having established that this latter script got "database is locked", I then rejigged the first script to fetch all the result rows before entering the slow loop. This sufficed to allow the second script to run without getting "database is locked" (i.e I didn't use ->finalize or ->close in the first script). I had a look at the PHP sqlite3 interface code, and it looks like ->query does prepare, step, and reset (if there are no errors). Which of these obtains the lock on the db? I also looked at PHP's ->finalize but in the case where there are no more rows to return, it didn't seem to do much of anything except return FALSE. Where will the lock have been dropped in the first script? -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
