[Zope-DB] DCOracle2 OracleDate and parameter sequence problem

[Matthew T. Kromer]

Christopher Jenkins wrote:

>Hi,
>
>I have recently started to use DCOracle2 beta5 (Oracle 9.0.1
>on Sparc Solaris and Python 2.1.1) and have encountered
>some strange problems when using OracleDate objects in
>parameter sequences and either execute() or executemany().
>
>To illustrate the problems, consider a table created by
>
>create table t (d date);
>
>Now from Python, if I have a cursor object cur
>
>>>>d=DCOracle2.TimestampFromTicks(time.time())
>>>>stmt = "insert into t values (:1)"
>>>>cur.execute(stmt, (d,))
>>>>
>4
>
>>>>cur.execute(stmt, (None,))
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/home/cjenkin1/oracle/DCO2/DCOracle2/DCOracle2.py", line 743, in
>execute
>    result = self._cursor.execute()
>dco2.DatabaseError: (1475, 'ORA-01475: must reparse cursor to change
>bind variable datatype')
>

Hmm... here you're inserting None as a date -- I dont think the code 
likes that -- probably a bug where
it shouldn't care, and just set the indicator to NULL.  Thats one where 
seeing the internal DCO2TRACEDUMP would help, because I'd see what the 
data type was bound as and what the indicator
was being set to, although I expect I can reproduce it.

>>>>cur.executemany(stmt, [(None,),(None,)])
>>>>
>4
>
>>>>cur.executemany(stmt, [(d,),(d,)])
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/home/cjenkin1/oracle/DCO2/DCOracle2/DCOracle2.py", line 837, in
>executemany
>    baoa[c][br] = p
>OverflowError: Assigned value too large  for Binding Array
>

This is a similar case, although I know there was a bug in executemany() 
dealing with the size of date types that's fixed in CVS.

>>>>cur.executemany(stmt, [(None,),(d,)])
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>  File "/home/cjenkin1/oracle/DCO2/DCOracle2/DCOracle2.py", line 837, in
>executemany
>    baoa[c][br] = p
>OverflowError: Assigned value too large  for Binding Array
>
>
>I have not encountered these problems when using other types
>(eg. floats).
>

Here's another None problem for the binding array; I dont know that the 
code scans all the data first before sizing the binding array -- I'll 
check into it -- it may only examine the sizes for certain types.