"Matthew T. Kromer" wrote:
I'm guessing it's something really nice and silly like you're not having ORACLE_HOME set for your other instances when you start Zope! The funny thing is, DCOracle2 should puke as well, if you don't have ORACLE_HOME set; the Oracle runtime needs that to go look at tnsnames.ora etc.
No, this is not the problem. The system vars are set in the login script, and I used the same user. Also, as I mentioned in a quick reply to my original post, I was able to use DCOracle directly from Python; it was only under Zope that it choked. Further, if you take a minute to look at the exception,
exceptions.TypeError Expected an Oracle Connection object
and where it happened,
Traceback (innermost last): [...] File /home/src/Zope-2.3.1-src/lib/python/Shared/DC/ZRDB/Connection.py, line 240, in connect (Object: RoleManager) File /home/src/test/Products/ZOracleDA/db.py, line 123, in __init__ File /home/src/test/Products/ZOracleDA/DCOracle/ocidb.py, line 90, in cursor File /home/src/test/Products/ZOracleDA/DCOracle/ociCurs.py, line 105, in __init__ BadRequest: (see above)
You get a strange picture: The library was able to open a connection, but when the connection object was passed again into C code for processing, it had the wrong type! I just moved this instance to DCO2 entirely as a solution. This worked almost perfect, except... (again, except...) Except that DCO2 returns the correct types for whole numbers, translating an Oracle INT, a.k.a. NUMBER(38), to a Python long. DCO1 did not, and returned it as int. Now, this wouldn't be a problem if dtml-var and dtml-sqlvar didn't write longs with the L suffix, so some of the argument passings get messed up. Solution? I don't have a real one. I patched DCO2 to make it behave wrong, because it seemed easiest. Perhaps it should be put in as an installation option. Or perhaps we need to fix the tags. In any case, 234L is not a legal constant in SQL (at least as implemeted by Oracle). Still wondering, Shai.