[Zope-DB] DCOracle2 OracleDate and parameter sequence problem
Matthew T. Kromer
Mon, 8 Oct 2001 08:18:00 -0400
OK, Its basically the same problem as executemany() -- when re-executing
a prior statement, the statement is not re-prepared. On an initial
execute, a NULL is bound as a SQLT_STR (string) type, so a subsequent
execute replacing it with a float (or anything non-string) requires a
re-prepare. When I get in to the office I'll put some code in that will
mark columns that are bound as NULL to trigger a re-prepare. Note that
tacking a space on to the end of your statement will serve as a
workaround, since this will also force a prepare.
On Monday, October 8, 2001, at 02:58 AM, Christopher Jenkins wrote:
> "Matthew T. Kromer" wrote:
>> Christopher Jenkins wrote:
>>> 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()
>> OK, I've fixed the problems you've reported in CVS.
>> Ken Mannheimer has directed all of my checkin messages to zope-db, of
>> which I'm a bit dubious, but my suggestion of "dont send them anywhere"
>> got shot down when someone complained about them showing up on the
>> zope-checkins list.
>> Howls about the checkin messages to me in private, please...
> Thank you very much for the prompt response. This has fixed
> the problem with OracleDate, but has uncovered a similar
> problem with float types (despite the comment in my origional
> If you have a table created by
> create table t (n float);
> Then from Python if you have a cursor object cur:-
>>>> stmt="insert into t values (:1)"
>>>> cur.execute(stmt, (None,))
>>>> cur.execute(stmt, (1.0,))
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "DCOracle2.py", line 766, in execute
> result = self._cursor.execute()
> dco2.DatabaseError: (1475, 'ORA-01475: must reparse cursor to change
> bind variable datatype')
> Note that in this case, the problem only manifests itself when the
> inserts are performed in this order (None first) which is why I did
> not pick it up earlier.
> This problem does not seem to affect executemany().
> I would very much appreciate your help with this issue.
> Thanks again for all your help,