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

[Matthew T.Kromer]

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