On 22 Oct 2013 at 09:11, Simon Slavin <slav...@bigfraud.org> wrote: > If you are writing code specifically intended for use with SQLite (like your > library was meant to be) then please use PHP's sqlite3 library rather than the > PDO. The advantage of using PDO is that if you transfer from one DBMS to > another, you only need to make minimal changes to your code. But the > disadvantage is that it doesn't understand how SQLite works very well, and > cannot take advantage of the things it does well or return the results it > produces well. The PDO library is useful if you are producing one set of code > that must work with lots of different SQL engines but because it's not native > to any of them it is its own layer that needs separate understanding and > debugging. > > PHP's sqlite3 library, on the other hand, contains just enough code to let you > handle sqlite3 databases using conventional PHP calls and objects, rather than > having to write C code. It doesn't need much documentation because you just > look up the equivalent functions in the SQLite3 documentation. It can do > everything that SQLite3 does, and provide all the information that SQLite3 > does.
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. 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. Of course, with PDO, that has internally involved fetching all the rows, which I could do myself but that seems clumsy. If I need columns x, y, z, I had wondered about doing: select count(*),x,y,z from sometable where …; or is that a bad idea? -- Cheers -- Tim
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
