DCOracle 1.32 weirdness -- quick help needed
Hi Zopers, Sorry for cross-posting -- I need help on this rather fast... I have been using ZOracleDA and DCOracle quite happily. Now, I needed to branch a "test" zope from the "dev" zope. As I was using the INSTANCE_HOME setup, this was a breeze: I shut zope down, copied the instance directory tree, meddled a little with the start scripts to give it different ports, fixed my httpd.conf, et voila. A new zope, up and running, independent of the first one. Except... Except that Oracle connections won't open. When I try to open them manually, they say, """ <strong>Invalid connection string: </strong><CODE>not/gonna@tellya</CODE><br> <!-- exceptions.TypeError Expected an Oracle Connection object --> <PRE> Traceback (innermost last): File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/src/Zope-2.3.2-src/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: RoleManager) File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/src/dev/../Zope-2.3/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_open_connection) File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_open_connection) File /home/src/Zope-2.3.1-src/lib/python/Shared/DC/ZRDB/Connection.py, line 220, in manage_open_connection (Object: RoleManager) 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) </PRE> """ At first I thought it was some stupid system thing, where the paths of the .pyc files were somehow encoded in them. So I went and deleted them all, and restarted, to no avail. Then I thought that it was the same problem, but with the python extensions. But it couldn't be: they were not built on this machine at all, and some files (Python's /lib/config/...) that are required in order to do this are missing. I have on the same Zope an installation of DCO2, patched to allow it to coexist with ZOracleDA. This works flawlessly. And ZOracleDA works flawlessly on the original, "dev" zope. Zope 2.3.2 ZOracleDA 2.1 (I think; only indication is the CHANGES.txt file) DCOracle 1.3.2 (I think) Oracle 8.0.5 (I don't think this matters) Red Hat 6.2 Any ideas? Thanks, Shai.
Zope 2.3.2 ZOracleDA 2.1 (I think; only indication is the CHANGES.txt file) DCOracle 1.3.2 (I think) Oracle 8.0.5 (I don't think this matters) Red Hat 6.2
Forgot to mention: Python 1.5.2 And testing the copied DCOracle from python works. Thanks, Shai.
Hi Shai, 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. The only difference between the two is DCOracle2 when self-built will bake in the library path of ORACLE_HOME/lib to its runtime load list, so it will be able to load successfully -- DCOracle doesn't do this, and the module won't even load. However, ZOracleDA sits on the whole thing and generally says "invalid connection string" regardless of what went wrong when trying to open a connection. PS, it's also fine to e-mail me directly about stuff like this -- I dont read the Zope lists as much as I should (in fact, I NEVER read zope@zope.org and only RARELY get around to reading zope-dev). Shai Berger wrote:
Hi Zopers,
Sorry for cross-posting -- I need help on this rather fast...
I have been using ZOracleDA and DCOracle quite happily. Now, I needed to branch a "test" zope from the "dev" zope. As I was using the INSTANCE_HOME setup, this was a breeze: I shut zope down, copied the instance directory tree, meddled a little with the start scripts to give it different ports, fixed my httpd.conf, et voila. A new zope, up and running, independent of the first one.
Except...
Except that Oracle connections won't open. When I try to open them manually, they say,
""" <strong>Invalid connection string: </strong><CODE>not/gonna@tellya</CODE><br> <!-- exceptions.TypeError Expected an Oracle Connection object --> <PRE> Traceback (innermost last): File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/src/Zope-2.3.2-src/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: RoleManager) File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/src/dev/../Zope-2.3/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_open_connection) File /home/src/Zope-2.3.2-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_open_connection) File /home/src/Zope-2.3.1-src/lib/python/Shared/DC/ZRDB/Connection.py, line 220, in manage_open_connection (Object: RoleManager) 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)
</PRE> """
At first I thought it was some stupid system thing, where the paths of the .pyc files were somehow encoded in them. So I went and deleted them all, and restarted, to no avail.
Then I thought that it was the same problem, but with the python extensions. But it couldn't be: they were not built on this machine at all, and some files (Python's /lib/config/...) that are required in order to do this are missing.
I have on the same Zope an installation of DCO2, patched to allow it to coexist with ZOracleDA. This works flawlessly. And ZOracleDA works flawlessly on the original, "dev" zope.
Zope 2.3.2 ZOracleDA 2.1 (I think; only indication is the CHANGES.txt file) DCOracle 1.3.2 (I think) Oracle 8.0.5 (I don't think this matters) Red Hat 6.2
Any ideas?
Thanks, Shai.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
"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.
participants (3)
-
Matthew T. Kromer -
Shai Berger -
Shai Berger