AW: [Zope-DB] [ANN] Modified version of DCOracle2 is available - RE Dr. Klaus Happle fixes
Hello - I was checking your fixes (Dr. Klaus Happle) for the two functions in dco2.c: (RE: http://mail.zope.org/pipermail/zope-db/2006-November/004812.html ) static PyObject *Cursor_ResultSet(Cursor *self, int count)and static PyObject *Cursor_fetch(Cursor *self, PyObject *args) I noticed that in the **original** dco2.c we have: 1. In static PyObject *Cursor_ResultSet(Cursor *self, int count): #ifndef ORACLE8i rs-fetchResultCode = OCI_SUCCESS; #endif 2. In static PyObject *Cursor_fetch(Cursor *self, PyObject *args): #ifndef ORACLE8i if (status == OCI_SUCCESS_WITH_INFO) { for (i = 0; i PyList_Size(self-results); i++) { rs = (ResultSet *) PyList_GetItem(self-results, i); rs-fetchResultCode=status; } } #endif In both cases, you got rid of #ifndef ORACLE8i in your fixes of the two functions. I am just curious as to why these ifndef's were removed. Can someone please clarifiy. Note: in dco2.c we have: #ifdef ORACLE9i # ifndef ORACLE8i # define ORACLE8i # endif #endif so with the #ifndef ORACLE8i, I imagine with the original code did not compile the statements above with Oracle 8 or Oracle 9 detected. I am curious how removing the #ifndef ORACLE8i condition in the fixes to the two functions would affect things at large. Thanks, Maan ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
AW: [Zope-DB] [ANN] Modified version of DCOracle2 is available - RE Dr. Klaus Happle fixes
Hello, your base is DCOracle2, 1.3 beta. But my base and fix was for DCOracle2, 1.2 The Successor (?) of DCOracle2 was reported/initiated from Maciej Wisniowski in http://mail.zope.org/pipermail/zope-db/2006-November/004789.html The base of this development was not the version 1.3 and so we can understand the differnce. When you will use the Version DCOracle2, 1.3 beta, then you must merge the differences or the essentials of my bugfix, which I describe in: http://mail.zope.org/pipermail/zope/2005-August/160762.html Klaus Happle -Ursprüngliche Nachricht- Von: Maan M. Hamze [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 2. Dezember 2007 20:29 An: zope-db@zope.org Cc: Happle Dr., Klaus Martin Betreff: AW: [Zope-DB] [ANN] Modified version of DCOracle2 is available - RE Dr. Klaus Happle fixes Hello - I was checking your fixes (Dr. Klaus Happle) for the two functions in dco2.c: (RE: http://mail.zope.org/pipermail/zope-db/2006-November/004812.html ) static PyObject *Cursor_ResultSet(Cursor *self, int count)and static PyObject *Cursor_fetch(Cursor *self, PyObject *args) I noticed that in the **original** dco2.c we have: 1. In static PyObject *Cursor_ResultSet(Cursor *self, int count): #ifndef ORACLE8i rs-fetchResultCode = OCI_SUCCESS; #endif 2. In static PyObject *Cursor_fetch(Cursor *self, PyObject *args): #ifndef ORACLE8i if (status == OCI_SUCCESS_WITH_INFO) { for (i = 0; i PyList_Size(self-results); i++) { rs = (ResultSet *) PyList_GetItem(self-results, i); rs-fetchResultCode=status; } } #endif In both cases, you got rid of #ifndef ORACLE8i in your fixes of the two functions. I am just curious as to why these ifndef's were removed. Can someone please clarifiy. Note: in dco2.c we have: #ifdef ORACLE9i # ifndef ORACLE8i # define ORACLE8i # endif #endif so with the #ifndef ORACLE8i, I imagine with the original code did not compile the statements above with Oracle 8 or Oracle 9 detected. I am curious how removing the #ifndef ORACLE8i condition in the fixes to the two functions would affect things at large. Thanks, Maan ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: AW: [Zope-DB] [ANN] Modified version of DCOracle2 is available
you remember my report http://mail.zope.org/pipermail/zope/2005-August/160762.html of an BUG for the handling of LONGs in DCO2? In fact I forgot about this... The consequence of this BUG is stochastic results for LONG fields We use an Fix of this BUG: I've put your code into dco2.c. Thank you very much for these fixes. -- Maciej Wisniowski ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
AW: [Zope-DB] [ANN] Modified version of DCOracle2 is available
Hi you remember my report http://mail.zope.org/pipermail/zope/2005-August/160762.html of an BUG for the handling of LONGs in DCO2? The consequence of this BUG is stochastic results for LONG fields We use an Fix of this BUG: Hint: The Documentation of the OCI from Oracle say us: defnp (IN), iter (IN), bufpp (OUT), alenpp (IN/OUT), piecep (IN/OUT), indpp (IN), rcodep (IN) Caution: When working with callback parameters, it is important to keep in mind what is meant by IN and OUT for the parameter mode. Normally, in an OCI function, an IN parameter refers to data being passed to Oracle, and an OUT parameter refers to data coming back from Oracle. In the case of callbacks, this is reversed. IN means data is coming from Oracle into the callback, and OUT means data is coming out of the callback and going to Oracle. Docu from OCI for OCIDefineByPos: indp (IN/OUT), alenp (IN/OUT), rcodep (OUT): Ignored for dynamic binds. First we fix Cursor_ResultSet and Second we fix Cursor_fetch: First Fix: static PyObject *Cursor_ResultSet(Cursor *self, int count) { PyObject *list; ResultSet *rs; int status; int i; sword mode = OCI_DEFAULT; dvoid *valuep; ub4 width; LongFetch *lf; TRACE(T_ENTRY,(sAd, Cursor_ResultSet, self, count)); if (self-definition == NULL) { TRACE(T_ERROR,(ss,Cursor_ResultSet,description is NULL)); PyErr_SetString(ProgrammingErrorObject, cursor description is None); return NULL; } self-batchsz = count; if ((list = Py_BuildValue([])) == NULL) { TRACE(T_ERROR,(ss,Cursor_ResultSet, PyBuildValue returned NULL)); return NULL; } for (i = 1; i = PyList_Size(self-definition); i++) { mode = OCI_DEFAULT; if ((rs = (ResultSet *) ResultSet_alloc(self, i, count)) == NULL) { Py_DECREF(list); TRACE(T_ERROR,(ss,Cursor_ResultSet, ResultSetAlloc returned NULL)); return NULL; } valuep = rs-valuep; width = rs-width; rs-fetchResultCode = OCI_SUCCESS; if (self-flags LONG_COLUMN (char) i == self-longcol) { mode = OCI_DYNAMIC_FETCH; lf = (LongFetch *) rs-valuep; longFetchInit(lf); /*valuep = NULL;*/ width = 0x7FFF; /* Max unsigned long */ 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 } TRACE(T_CALL,(sdAddd, OCIDefineByPos, i, valuep, width, rs-cdty, mode)); /* Now bind the result set */ /* Docu from OCI: indp (IN/OUT), alenp (IN/OUT), rcodep (OUT): Ignored for dynamic binds. */ status = OCIDefineByPos(self-stmtp, (rs-defnp), self-errhp, i, valuep, width, rs-cdty, (dvoid *) rs-indp, rs-rlenp, rs-rcodep, mode); TRACE(T_RETURN,(sR, OCIDefineByPos, status)); if (status != OCI_SUCCESS) { Py_DECREF(rs); Py_DECREF(list); return RaiseOCIError(self-errhp, OCI_HTYPE_ERROR); } if (self-flags LONG_COLUMN (char) i == self-longcol) { TRACE(T_CALL,(sA, OCIDefineDynamic, rs-valuep)); status = OCIDefineDynamic(rs-defnp, self-errhp, (dvoid *) rs-valuep, (OCICallbackDefine) dynamicFetch); TRACE(T_RETURN,(sR, OCIDefineDynamic, status)); if (status != OCI_SUCCESS) { Py_DECREF(rs); Py_DECREF(list); return RaiseOCIError(self-errhp, OCI_HTYPE_ERROR); } } PyList_Append(list, OBJECT(rs)); Py_DECREF(rs); /* Now that its in the list ... */ } if (self-results != NULL) { Py_DECREF(self-results); } self-results = list; self-current = 0; Py_INCREF(Py_None); TRACE(T_EXIT,(s,Cursor_ResultSet)); return Py_None; } Second Fix: