[Zope-DB] DCOracle2 1.3beta executemany() dco2.DatabaseError

[Lee, Bryson]

So does this mean that if the centrally-managed Oracle + client library installation here at my site gets upgraded, I might need to change back and comment out the baoa[c].setStatic(1) call in cursor.executemany()?

Or is it that with Oracle 9i on Redhat Enterprise Linux 3, dynamic binds don't work for INSERT operations?

I've rolled my own DCOracle2 module and set my PYTHONPATH, so I'm divorced from our central (broken?) DCOracle2 installation, but I'm curious to know if I need to watch for future occurrances of this type of failure, given that I'm not in administrative control of the total software set on our Unix farm.

I reported this as issue 1709 in the Zope Collector, but I suppose that should be closed if it's an oracle problem...

Regards,

Bryson

-----Original Message-----
From: Matthew T. Kromer [mailto:matt at bane.mi.org] 
Sent: Wednesday, February 23, 2005 12:58 PM
To: Lee, Bryson
Cc: zope-db at zope.org
Subject: Re: [Zope-DB] DCOracle2 1.3beta executemany() dco2.DatabaseError

Its a problem with "How does Oracle want this done" :)

I'd argue its ultimately an oracle bug with dynamic binds that it doesn't work for you.  That's usually associated with prefetching, so turning prefetching off usually lets the dynamic binds work all the time.

Some things won't work right with static binds, some wont work right with dynamic binds.  As I recall, its a total pain to try to figure out which situation is which.

OTOH, I'm glad changing flipping dynamic to static works for you.


On Feb 22, 2005, at 4:54 PM, Lee, Bryson wrote:

> Hmmm...
>
> The problem seems to be assocated with a one-line change in the
> executemany() method in DCOracle2.py...
>
> Around line 1130, there is a call to the setStatic() method of a 
> BindingArray object.  In the 1.95 version of DCOracle2, this line is 
> uncommented, which seems to imply that the parameter binding is static 
> for that version.
>
> In the 1.99 and 1.103 (latest CVS) versions of DCOracle1.py, this line 
> is commented out, indicating that a non-static binding is being used.
> If I uncomment this line in the 1.103 version and re-run my insert 
> task, I no longer get the exception, and thus executemany() appears to 
> work OK for arbitrary-length lists.
>
> It appears that this line was first commented out in 1.96.  The commit 
> log message for 1.96 makes no reference to this change, only to some 
> changes in code for handling DATE types.  Makes me wonder if this was 
> a debug or platform-specific thing that inadvertently got committed to 
> the repository.
>
> Regards,
>
> Bryson
>
> -----Original Message-----
> From: zope-db-bounces at zope.org [mailto:zope-db-bounces at zope.org] On 
> Behalf Of Lee, Bryson
> Sent: Tuesday, February 22, 2005 12:38 PM
> To: Matthew T. Kromer
> Cc: zope-db at zope.org
> Subject: RE: [Zope-DB] DCOracle2 1.3beta executemany() 
> dco2.DatabaseError
>
> I've built from the latest CVS tarball (DCOracle2 1.103, dco2 1.137) 
> and added the setPrefetch(0) call, but I still get the same exception.
>
> -Bryson
>
> -----Original Message-----
> From: Matthew T. Kromer [mailto:matt at bane.mi.org]
> Sent: Friday, February 11, 2005 10:17 AM
> To: Lee, Bryson
> Cc: zope-db at zope.org
> Subject: Re: [Zope-DB] DCOracle2 1.3beta executemany() 
> dco2.DatabaseError
>
> Here's something to try - -turn off cursor prefetching with
> cursor.setPrefetch(0)
>
> Also, the latest cvs build of dco2.so is 1.137 or so, so you're 
> running about 8 patches behind at your current code base.
>
> On Feb 10, 2005, at 6:42 PM, Lee, Bryson wrote:
>
>> With the following Python / DCOracle2 combination:
>>
>> Python sys.version =
>> 2.3.3 (#1, Apr  7 2004, 09:31:28)
>> [GCC 2.95.3 20010315 (release)]
>>
>> DCOracle2.version =
>> 1.3 beta -- DCOracle2 1.99 (dco2: 1.129 -DORACLE8i -DUSEOBJECT 
>> -Dlinux
>> -DNATIVENUMERIC=1 -D_REENTRANT )
>>
>> I get an exception if I call the executemany() method on a cursor if 
>> the input record list has more than 12 items:
>>
>> dco2.DatabaseError: (1400, 'ORA-01400: cannot insert NULL into
>> ("GLAST_ISOC"."V2HKVALCHFIELDS"."SOURCE")')
>>
>> If the list has 12 or fewer items, the call works perfectly well.
>>
>> Using the same code to process the same data-set under Python 2.2.2 
>> and DCOracle2 1.2 / 1.95 / dco2 1.120, the executemany() call works 
>> correctly regardless of the length of the input record list.
>>
>> Has anybody else seen this sort of behavior?
>>
>> I can supply a dco2.tracedump of the failed call, if that helps
>>
>> Regards,
>>
>> Bryson Lee
>> _______________________________________________
>> Zope-DB mailing list
>> Zope-DB at zope.org
>> http://mail.zope.org/mailman/listinfo/zope-db
>
> _______________________________________________
> Zope-DB mailing list
> Zope-DB at zope.org
> http://mail.zope.org/mailman/listinfo/zope-db