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/