Problem with sqlite3 cursor and imbricated for loop

[Steve Holden]

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/