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
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
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
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
Paul Boddie wrote:
> On 4 Feb, 20:30, John Nagle <[EMAIL PROTECTED]> wrote:
>>This has me completely mystified. Some SELECT operations performed
>> through
>> MySQLdb produce different results than with the MySQL graphical client.
>> This failed on a Linux server running Python 2.5, and I can
Steve Holden wrote:
> John Nagle wrote:
>> Carsten Haese wrote:
>>> On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote:
Restarting the MySQL instance changes the database. The entry
"google.com"
disappears, and is replaced by "www.google.com". This must indicate
a hanging
>
On 5 feb, 01:42, Steve Holden <[EMAIL PROTECTED]> wrote:
> John Nagle wrote:
> > Carsten Haese wrote:
> >> On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote:
> >>> Restarting the MySQL instance changes the database. The entry
> >>> "google.com"
> >>> disappears, and is replaced by "www.google.c
John Nagle wrote:
> Carsten Haese wrote:
>> On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote:
>>> Restarting the MySQL instance changes the database. The entry "google.com"
>>> disappears, and is replaced by "www.google.com". This must indicate a
>>> hanging
>>> transaction that wasn't commit
Carsten Haese wrote:
> On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote:
>> Restarting the MySQL instance changes the database. The entry "google.com"
>> disappears, and is replaced by "www.google.com". This must indicate a
>> hanging
>> transaction that wasn't committed.
>>
>> But that trans
On Mon, 2008-02-04 at 11:30 -0800, John Nagle wrote:
> Restarting the MySQL instance changes the database. The entry "google.com"
> disappears, and is replaced by "www.google.com". This must indicate a hanging
> transaction that wasn't committed.
>
> But that transaction didn't come from the Pyt
This has me completely mystified. Some SELECT operations performed through
MySQLdb produce different results than with the MySQL graphical client.
This failed on a Linux server running Python 2.5, and I can reproduce it
on a Windows client running Python 2.4. Both are running MySQL 2.5.
The
11 matches
Mail list logo