All right, I made DCOracle2-PR1 and copied the dco2.so to my /usr/lib/python2.1/site-packages/ directory. I go into python to test it out, here's what I get: Python 2.1.3 (#1, Apr 11 2002, 00:19:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information.
import dco2 db = dco2.connect("xxxxx", "xxxxx", "xxxxx") dbc = db.cursor() dbc.execute("select * from table") Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: an integer is required
Any ideas? Thanks, Sean
Sean Abrahams wrote:
All right, I made DCOracle2-PR1 and copied the dco2.so to my /usr/lib/python2.1/site-packages/ directory.
I go into python to test it out, here's what I get:
Python 2.1.3 (#1, Apr 11 2002, 00:19:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information.
import dco2 db = dco2.connect("xxxxx", "xxxxx", "xxxxx") dbc = db.cursor() dbc.execute("select * from table")
Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: an integer is required
Any ideas?
Thanks, Sean
My guess is a column which was supposed to have a date in it has a NULL date... not sure though. I'm going to upload rel 1.1 this morning, which has some fixes in it. -- Matt Kromer Zope Corporation http://www.zope.com/
Matthew, I updated to 1.1 that you uploaded an am still getting the same error. Running dco2 on my linux test box, and accessing an oracle 8.1.6 server on a ibm unix 4.3 box. I get the error no matter what table i query, with or without a date field, and even if i misspell the table name. since connecting and querying seems to work (ie data is getting sent and returned), this is most likely not a fault of a bad build or other module correct? I'm relatively new to gnu/linux and still learning everyday. cx_Oracle works fine, but I wanted to use DCOracle2 for Zope and its callproc() feature. What do you suggest I do? Thanks for your help, Sean Tuesday, April 23, 2002, 7:22:33 AM, you wrote: MTK> Sean Abrahams wrote:
All right, I made DCOracle2-PR1 and copied the dco2.so to my /usr/lib/python2.1/site-packages/ directory.
I go into python to test it out, here's what I get:
Python 2.1.3 (#1, Apr 11 2002, 00:19:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information.
import dco2 db = dco2.connect("xxxxx", "xxxxx", "xxxxx") dbc = db.cursor() dbc.execute("select * from table")
Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: an integer is required
Any ideas?
Thanks, Sean
MTK> My guess is a column which was supposed to have a date in it has a NULL MTK> date... not sure though. MTK> I'm going to upload rel 1.1 this morning, which has some fixes in it.
Sean Abrahams wrote:
Matthew,
I updated to 1.1 that you uploaded an am still getting the same error. Running dco2 on my linux test box, and accessing an oracle 8.1.6 server on a ibm unix 4.3 box.
I get the error no matter what table i query, with or without a date field, and even if i misspell the table name.
since connecting and querying seems to work (ie data is getting sent and returned), this is most likely not a fault of a bad build or other module correct?
I'm relatively new to gnu/linux and still learning everyday.
cx_Oracle works fine, but I wanted to use DCOracle2 for Zope and its callproc() feature.
What do you suggest I do?
OK, Step 1: export DCO2TRACEDUMP=dco2.tcd export DCO2TRACEFLAGS=255 ... run your python program ... Step 2: Go to http://www.zope.org/Members/matt/dco2/Tracker and open a problem report, uploading the tracedump from step 1. Edit the file if necessary to remove any plaintext you don't want others to see (like passwords if they appear). If that doesnt work, I need better tracebacks for why an integer is required -- "stdin line 1" is not helpful, since it doesn't tell me what the statement was that failed. If that STILL doesn't work, then I need to see the schema description for your table, which you can get from DCOracle2 by doing the following db = DCOracle2.connect(connectstring) d = db.describe(SCHEMANAME) # most schema names are all caps e.g. "TABLE" print db.decodedesc(d) If the decoding fails, then I will look at the raw description: import pprint pprint.pprint(d) There are certain things DCOracle2 doesn't do, like Oracle objects, so I need to see the schema data to make sure it isn't getting back anything that it should be doing, but isn't. -- Matt Kromer Zope Corporation http://www.zope.com/
Matthew, All right, cancel all the previous messages out. Looks like it was an install and usage error on my side. Thanks for all the tips and I apologize for any frustration caused. Just so you know, I was importing dco2 instead of DCOracle2. Of course, it also helps when the installer isn't a newbie. Thanks, Sean Tuesday, April 23, 2002, 9:57:34 AM, you wrote: MTK> Sean Abrahams wrote:
Matthew,
I updated to 1.1 that you uploaded an am still getting the same error. Running dco2 on my linux test box, and accessing an oracle 8.1.6 server on a ibm unix 4.3 box.
I get the error no matter what table i query, with or without a date field, and even if i misspell the table name.
since connecting and querying seems to work (ie data is getting sent and returned), this is most likely not a fault of a bad build or other module correct?
I'm relatively new to gnu/linux and still learning everyday.
cx_Oracle works fine, but I wanted to use DCOracle2 for Zope and its callproc() feature.
What do you suggest I do?
MTK> OK, MTK> Step 1: MTK> export DCO2TRACEDUMP=dco2.tcd MTK> export DCO2TRACEFLAGS=255 MTK> ... run your python program ... MTK> Step 2: MTK> Go to http://www.zope.org/Members/matt/dco2/Tracker and open a MTK> problem report, uploading the tracedump from step 1. Edit the file if MTK> necessary to remove any plaintext you don't want others to see (like MTK> passwords if they appear). MTK> If that doesnt work, I need better tracebacks for why an integer is MTK> required -- "stdin line 1" is not helpful, since it doesn't tell me what MTK> the statement was that failed. MTK> If that STILL doesn't work, then I need to see the schema description MTK> for your table, which you can get from DCOracle2 by doing the following MTK> db = DCOracle2.connect(connectstring) MTK> d = db.describe(SCHEMANAME) # most schema names are all caps e.g. MTK> "TABLE" MTK> print db.decodedesc(d) MTK> If the decoding fails, then I will look at the raw description: MTK> import pprint MTK> pprint.pprint(d) MTK> There are certain things DCOracle2 doesn't do, like Oracle objects, so I MTK> need to see the schema data to make sure it isn't getting back anything MTK> that it should be doing, but isn't.
participants (2)
-
Matthew T. Kromer -
Sean Abrahams