More details here. The error is occurring on the first call to
cursor.execute in the process (and all subsequent calls), so not likely
a matter of leftover cursors or cursors hanging around from previous
calls within the process. First query is:
DECLARE "PgSQL_01323DF01" CURSOR FOR SELECT tablename FROM pg_tables
WHERE tablename !~ '^pg_' AND tablename !~ '^pga_';
setting noPostgresCursor true works around the effect (i.e. the queries
work fine). (Note: the passed in query starts with "SELECT", the cursor
class is adding the declare when noPostgresCursor is false).
As to why I can't provoke the darned thing to show the same error with a
script executing the same query, no clue. I'm assuming it's some weird
effect of, for instance, not having a hard reference to a connection
anywhere (though that fails in a different way in my tests), or some
weird interaction with the apps logging DB connection (though that's not
getting called in the test, and simulating it's existence with another
connection doesn't affect anything), or bad karma left over from some
previous life :) .
For now I'll just set noPostgresCursor true and get back to real work,
but I would still be very curious to see what others think might cause
such an effect.
Have fun,
Mike
Mike C. Fletcher wrote:
...
> Traceback (most recent call last):
> File "p:\sharedinstall\pyPgSQL\PgSQL.py", line 3098, in execute
> self.res = self.conn.conn.query(_qstr % parms)
> OperationalError: ERROR: cursor "PgSQL_013CAD78" already exists
...
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
|
