AW: [Zope] Re: Oracle 9.2.0.2

[Happle Dr., Klaus Martin]

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:maciej.wisniowski at coig.katowice.pl] 
Gesendet: Montag, 1. August 2005 11:09
An: Dieter Maurer; zope at 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