On 08 Feb 2014 at 17:48, Simon Slavin <slav...@bigfraud.org> wrote: > On 8 Feb 2014, at 4:58pm, Tim Streater <t...@clothears.org.uk> wrote:
>> 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). > > If ->query() is doing 'step()' then the PHP code does not work the same way > SQLite3 does internally. SQLite would do 'step()' as part of ->fetchArray(). ->query is only doing the one step(). If it gets SQLITE_ROW or SQLITE_DONE from that, then it does the reset, otherwise it returns an error. ->fetchArray() certainly does one step() each time it is called. >> Which of these obtains the lock on the db? > > The first 'step()'. Before then all PHP needs to know is the structure of the > database, not about the data in it. The database needs to be locked from the > first 'step()' to the last 'step()', though it can predict that it is finished > if 'step()' returns 'no more rows'. OK. > So putting the above together you are still expected to use ->finalize() on > the result set: it is the ->close() for that class and is the official way to > release the handle. Don't set it to null manually, use ->finalize() on it. > And, of course, eventually use ->close() on the database handle. > > Your solution may work for your test case, and it may work for this version of > PHP using this version of SQLite, but I would recommend you use the API as > documented. OK - thanks, that's clearer now. -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
