[Zope-dev] DCOracle 1.32 weirdness -- quick help needed

Shai Berger shai@platonix.com
Thu, 09 Aug 2001 16:08:13 +0300


"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.