Re: Must COMMIT after SELECT

2008-02-07 Thread M.-A. Lemburg
On 2008-02-07 16:46, Carsten Haese wrote: > On Thu, 2008-02-07 at 16:33 +0100, M.-A. Lemburg wrote: >> mxODBC has support for named cursors that you can later >> use for positioned updates. > > Since we're on the topic of shameless plugs, InformixDB has this > feature, too :) > >> However, it's

Re: Must COMMIT after SELECT

2008-02-07 Thread Carsten Haese
On Thu, 2008-02-07 at 16:33 +0100, M.-A. Lemburg wrote: > mxODBC has support for named cursors that you can later > use for positioned updates. Since we're on the topic of shameless plugs, InformixDB has this feature, too :) > > However, it's usually better to do updates in the classical > way,

Re: Must COMMIT after SELECT

2008-02-07 Thread M.-A. Lemburg
On 2008-02-07 14:29, Steve Holden wrote: > Paul Boddie wrote: >> With PostgreSQL, my impression is that the intended way of using >> cursors is not entirely compatible with the DB-API: you declare >> cursors only when you know what the query will be, not in advance, and >> they can only be used wit

Re: Must COMMIT after SELECT

2008-02-07 Thread Steve Holden
Paul Boddie wrote: [...] > > I don't use psycopg2 at the moment, but I did patch it to allow more > transparent usage of cursors, and there's an unapplied patch for this > floating around in the bug tracker. Lately, I've been using pyPgSQL > instead and not really doing huge selects from Python co

Re: Must COMMIT after SELECT

2008-02-07 Thread Paul Boddie
On 7 Feb, 14:29, Steve Holden <[EMAIL PROTECTED]> wrote: > > That's true, and your remarks clarify cursor usage in the DB API very > well. Most people most of the time tend to ignore the existence of > cursor.fetchmany() in the DB API, despite the fact that it can provide > huge efficiency gains ov

Re: Must COMMIT after SELECT

2008-02-07 Thread Steve Holden
Paul Boddie wrote: > On 7 Feb, 08:52, Frank Aune <[EMAIL PROTECTED]> wrote: >> On Wednesday 06 February 2008 16:16:45 Paul Boddie wrote: >> >>> Really, the rule is this: always (where the circumstances described >>> above apply) make sure that you terminate a transaction before >>> attempting to re

Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-07 Thread Paul Boddie
On 7 Feb, 08:52, Frank Aune <[EMAIL PROTECTED]> wrote: > On Wednesday 06 February 2008 16:16:45 Paul Boddie wrote: > > > Really, the rule is this: always (where the circumstances described > > above apply) make sure that you terminate a transaction before > > attempting to read committed, updated d

Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-06 Thread Frank Aune
On Wednesday 06 February 2008 16:16:45 Paul Boddie wrote: > Really, the rule is this: always (where the circumstances described > above apply) make sure that you terminate a transaction before > attempting to read committed, updated data. How exactly do you terminate a transaction then?Do you term

Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-06 Thread Paul Boddie
On 6 Feb, 16:04, Frank Aune <[EMAIL PROTECTED]> wrote: > > Whenever I did a SELECT() on the first connection, the cursor would > stop "seeing" new entries commited in the log table by the other connection. > I always assumed you needed COMMIT() after adding new content to the > database, not after

Re: Must COMMIT after SELECT (was: Very weird behavior in MySQLdb "execute")

2008-02-06 Thread Frank Aune
On Tuesday 05 February 2008 18:58:49 John Nagle wrote: > So you really do have to COMMIT after a SELECT, if you are reusing > the database connection. CGI programs usually don't have this issue, > because their connections don't live long, but long-running FCGI (and maybe > Twisted) programs d