It means exactly what it says -- someone closed the cursor (or the
connection the cursor was based on) and then tried to use the cursor.
It might be related to a stored procedure -- those things squirrel
away the cursor they were created on for later use.
On Apr 1, 2005, at 12:17 AM, Chris Wit
Chris Withers's branch of DCOracle2 has some changes that help the
connection pooling problem.
The issue basically is that the Zope adapter for DCOracle2 is fairly
old and crusty. I think Jim's correct when he suggests doing your own
pool management from a module.
All that the DA is supposed
On Apr 19, 2005, at 4:24 AM, Chris Withers wrote:
Matthew T. Kromer wrote:
Chris Withers's branch of DCOracle2 has some changes that help the
connection pooling problem.
And rumour has it I'm going to get some serious time to work on this
soon! Matt, you up for fixing any C-level bugs
You can get the newer code from cvs.zope.org. The particular error
your getting usually indicates a permission problem with ORACLE_HOME's
directory or not having the ORACLE_HOME environment variable set
properly. The libraries can't even read the message repository in this
instance.
O
Not sure, but I think DCOracle2 includes both Python.h and stdio.h --
try removing stdio.h and making the python.h include the first include.
On Sep 28, 2005, at 2:38 PM, Seth Gottlieb wrote:
I have been trying to compile DCOracle2 and found the instructions
from "evstumpf at ucdavis."
Wh
e slightly differently.
On Sep 28, 2005, at 10:34 PM, Seth Gottlieb wrote:
Thanks for responding. I commented out line 92:
#include
and moved
#include
(which was around line 126) to the first of the includes. I still get
the same error message. Anything else to try?
Thanks,
Seth
Matthew T. Kr
However, a colleague found out that for his (probably special kind
of) setup, "cxOracle" was much slower than DCOracle2 (by about
a factor of 4).
heh, well I like to write FAST code when I can ;) However, the Zope
DA/RDBMS machinery slows the db conection down enormously -- like 9x
if
It's probably the TRACE macro which is generating a lot of these
messages, if you don't need to be able to do runtime tracing (for
diagnostics) then you can tweak the #define TRACE(condition,args) to
be a no-op macro -- just delete the body of the macro.
On Mar 14, 2006, at 2:54 PM, Dieter
I'm pretty confident that the db component (the C layer) doesn't have
any GIL problems. However, the DA component (the Zope layer) *may*
have all sorts of unusual failure modes.
Debugging transaction concurrency problems is always tricky, but keep
in mind there are Python layer abstraction
Basically, no.
You could recode DA's to close the connection at the end of every
transaction and reopen them on demand, but to the best of my
knowledge none of the DAs work that way.
Once a connection object opens its connection it stays open but in
the object cache of that thread. This
On Oct 13, 2006, at 5:14 AM, Chris Withers wrote:
I have to echo Jens' sentiments though: why not just ship .py files
and be done with it?
If I had to make a wild-ass guess, its because there's an indication
that the mxodbc code would be misappropriated and proliferated
outside of
If I recall, DCOracle2 returns an array of the OUT parameters from
invoking a stored procedure, so your invocation would be more like
c2 = c1.sp1(in1, in2, in3, in4) and you wouldn't pass in ref_cur
but its been a while since I reviewed the code. I know ref cursors
used to work...
On Mar
Chances are good that the C code that is trying to construct the
timestamp doesn't know how to convert it...
A quick peek into the source code hints the code doesn't have a type
converter for SQLT_TIMESTAMP, although there is a converter for
SQLT_DAT (date).
Putting a converter into the C
Maybe then we would know if CONVERTOUTF
(SQLT_DAT) is producing error or simply the absence of CONVERTOUTF
(SQLT_TIMESTAMP) is causing it.
Maan
- Original Message - From: "Matthew T. Kromer"
<[EMAIL PROTECTED]>
To: "Maan M. Hamze" <[EMAIL PROTECTED]
14 matches
Mail list logo
