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, ...,
15-77)
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)) {
Py_INCREF(Py_None);
....(TRACES)....
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; zope@zope.org
Betreff: Re: [Zope] Re: Oracle 9.2.0.2
>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 - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
