c.execute("select * from stocks")
for s in list(c):
print s[0]
c.execute("select * from stocks where price<20")
for sp in c:
print ' '+sp[0]
c.close()
The simple addition of list() should do away with the dependency on
mysql's implementation, since it forces the instant fetch of al
Gerhard Häring wrote:
> Steve Holden wrote:
[...]
>>>
>> It's also why SQLite's not a real RDBMS. Fortunately this doesn't stop
>> it being very useful.
>
> What does pysqlite extending the DB-API have to do with *SQLite* not
> being a "real" RDBMS?
>
Nothing at all. I was just being pissy. Sorry
Charles V. wrote:
Hi,
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 curs
Steve Holden wrote:
[...]
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 ...
No, I just find code like:
con
Hi,
> 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 rea
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, whic
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 ? I was expecting the same behavior than
> MySQLdb module, which is, as sqlite3, DB-API 2.0 compatible.
>
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 ma
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 ? I was expecting the same behavior than
MySQLdb module, which is, as sqlite3, DB-API 2.0 compatible.
It means a program written for MySQ
Charles V. wrote:
It seems the second call to execute modify the first cursor. Is it normal ?
How am I suppose to write this ?
Maybe introduce a second cursor?
import sqlite3
conn = sqlite3.connect(':memory:')
c = conn.cursor()
d = conn.cursor() # second cursor
c.execute('''create table stock
Hi,
I hope this is not already known. But Google wasn't any help. So here begins a
script to explain my problem.
-
import sqlite3
conn = sqlite3.connect(':memory:')
c = conn.cursor()
c.execute('''create table stocks
(date text, trans text, symbol text,
qty real, price re
11 matches
Mail list logo
