Very nice, so I can try it also with SQLRelay. The troubelsome is that SQLRelay 
comes not with a DB API 2.0 compatible Wrapper so we can't test it immediatly. 
The possible solutions to write a wrapper for SQLRelay or to reimplemented the 
database access in our scripts/environmnet taking up much time and so dependend 
from our time.

To the difficult bug in DCOracle2, I found the problem:

For the fetch of LONG variables the authors used a Long fetch holder 
"LongFetch" and the Oracle OCIDefineByPos in the OCI_DYNAMIC_FETCH mode. But in 
this mode one important variable (also two other variables but we can focus our 
interest to the important variable: the indicator which signalize NULL value) 
is ignored! see "Oracle Call Interface, Programmer's Guide" indp (IN/OUT), 
alenp (IN/OUT), rcodep (OUT) are Ignored for dynamic binds. (page 15-68, ..., 

So the methods to give the values from a field reported non-deterministically 
"None" because the indicator variable which is declared but not initialized can 
have every value and the if-statement
        indp = self->rs->indp;
        /* If the indicator is -1 (NULL) and the fetch result is
         * OCI_SUCCESS or OCI_SUCCESS_WITH_INFO, return None.
        if (*indp == -1 &&
                (self->rs->fetchResultCode==OCI_SUCCESS_WITH_INFO || 
                 self->rs->fetchResultCode==OCI_SUCCESS)) {
                return Py_None;

in ResultSetItem_value can non-deterministically return a Py_None.

The problem is that the authors doesn't synchronize the pointer of LongFetch 
with the pointer of the ResultSet-Object in the case of a OCI_DYNAMIC_FETCH 
mode, so we can results with wrong value None for non empty long fields 
(because the indicator is an noninitialized pointer).

When I synchronize the pointer with:
                        rs->indp = &lf->ind; //KMH, 2.8.2005 synchronisation of 
dynamicFetch with ResultSet
                        rs->rcodep = &lf->rcode; //KMH, 2.8.2005 
synchronisation of dynamicFetch with ResultSet at the points where the 
LongFetch are initialized (show longFetchInit) so the pointer variable indp of 
the ResultSet-Object become the correct value.

For the pointer "alenp" I have yet no solution because it was a ub2 pointer and 
the LongFetch have no equivalent (eg. the length is a long and so on). An 
adequate solution is only necessary when we would used the compiler symbol 
ZEROLENISNULL because in this case the values for non empty long fields can 
also results a None.

Klaus Happle

-----Urspr√ľngliche Nachricht-----
Von: Maciej Wisniowski [mailto:[EMAIL PROTECTED] 
Gesendet: Montag, 1. August 2005 11:09
An: Dieter Maurer;
Betreff: Re: [Zope] Re: Oracle

>A colleague of mine currently hunts a difficult bug in DCO2 which 
>causes wrong query results with a probability of about 0.0025 (non 
>empty "long" fields are non-deterministically reported as "None").
>He also tried cx_Oracle. It is more reliable but by a factor of 4 
>slower than DC02.
And what with SQLRelay? I did only one stupid test but SQLRelay was faster than 
DCOracle2 in it. SQLRelay has function that allows to set buffer size and 
optimize it to specific kind of queries.

Maciej Wisniowski
Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to