On 23 Oct 2013 at 15:02, Simon Slavin <[email protected]> wrote: > On 23 Oct 2013, at 1:15pm, Tim Streater <[email protected]> wrote: > >> HmmmOK. I'm therefore making a second attempt to use the sqlite3 PHP >> interface in my application instead of PDO. There will be about 35 modules to >> alter so I hope I can work through any issues. > > Sorry to put you to the work. Might be worth doing a little test first before > making all the changes in all the modules ?
I made a small library using PDO which encapsulates error handling, and a while ago I did the same for sqlite3 with the same interface (to the extent possible). I did some tests then and had some problems, can't remember what they were now, but enough to make me abandon the effort at the time. But I always wanted to get back to it. >> One wrinkle is that with the PDO interface, I can fetchAll and get an array >> of the rows returned from a SELECT, which allows me to count how many there >> were. This allows me to make an early exit if there are none. > > You can, buy all means, write your own fetchAll function which reads all the > rows and returns them as an array. I have several apps which have such a > function. By the way, even though as far as your code is concerned the > fetchAll allows you an early exit, it does actually have to fetch all the > rows, so it's still doing all the work involved in reading all the rows from > the database. Yes. In fact I suspect that where I need to, what I'll do is try to fetch the first row, and if that fails I know I have no rows. Then I can quit there or reset() and proceed normally. I don't *always* need to do that. About to start testing now, rework over modulo any typos and bugs. I suspect I'll have to do more stuff like finalise() and reset() which at present is being hidden for me in the PDO. -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
