Gerhard Häring wrote: > Charles V. wrote: >> Hi, >> >> Thank for replying. >> >>> Either use a second cursor OR ensure you fetch all the data from the >>> first .execute() first: >> >> Are these really the only solutions ? > > Yes. > >> I was expecting the same behavior than MySQLdb module, which is, as >> sqlite3, DB-API 2.0 compatible. > > Both may be standard compliant, but if you're depending on > implementation details, you may still get different behaviour. > I'm pretty sure that MySQLdb always fetches the entire resultset from > the server. The sqlite3 module uses what would have been called > "server-side cursors" in real databases, i. e. it only fetches rows on > demand. To fetch everything in one go with the sqlite3 module, you have > to call fetchall() explicitly. > >> It means a program written for MySQLdb won't be compatible with >> sqlite3 (even if I am using standard SQL). In fact I don't really >> understand why the iterator isn't in some way "encapsulated". [...] > > I feel with you. The fact that cursors, and not connection objects have > the executeXXX methods is totally braindead. > So you'd rather have to use separate connections? That would make isloated transaction processing a little tricky ...
> That's why pysqlite (sqlite3) has alternative nonstandard executeXXX > methods in the connection object that return cursors. > It's also why SQLite's not a real RDBMS. Fortunately this doesn't stop it being very useful. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list