Why is ORA-03106 in OCI program when more than 1 row is selected? Only 10g, not 11g

Annex my OCI returns ORA-03106 ( "fatal error protocol with two tasks") in the performance of SELECT * FROM mytable

which mytable

has four columns: INTEGER

, VARCHAR(1000)

, FLOAT

and DATE

and two rows. The call succeeds if there is only 1 line. The call also succeeds if there is a column in the table BLOB

(which is also selected).

Various forums have pointed out that NLS_LANG

related issues may be the cause, namely that the character set conversion is not performed on the client when retrieving the data because (possibly) character set conversion files cannot be found. Please note that I checked out a number of possible combinations of settings NLS_LANG

, NLS_CHARACTERSET

, ORA_NLS10

and other environmental variables. By setting certain of these influences the observed behavior: sometimes Oracle quits ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist

; at other times, the client application crashes before the first row is fetched (crash happens internally OCIStmtFetch2()

). It is notable that if the client application makes the following request when the connection is established first: ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '.,'

no crash occurs; an error is returned instead ORA-03106: fatal two-task communication protocol error

.

Note: It is possible that the column DATE

is causing this, but establishing reproducible cases has proven to be very difficult, so I am posting my question as is.

I've spent over 50 hours trying to fix this problem. Any help would be greatly appreciated.

NEW: Important additional information (see below code snippet)... The problem ONLY occurs during PIECEWISE data retrieval - it doesn't matter which of the two methods I use (dynamic callback function or loop method using get / set information functions). After going through the debugger and looking at the in-memory buffers I provided to OCI to store the FETCHED data, all 4 fields in the first line are always retrieved as expected; the initial FETCH of the second column (this is the call that is returned asking for information about the VARCHAR column when using the looping approach) successfully populates all non-dynamic fields up to, but does not include the VARCHAR column (i.e. the INTEGER column is correctly populated); then the next FETCH successfully populates the VARCHAR field and should successfully populate the remaining (non-dynamic) columns (FLOAT and DATE fields); however the FLOAT field is correctly filled,but the DATE field is corrupted and furthermore this FETCH call should return success, but instead it returns ORA-03106.

The following piece of code, stripped of irrelevant error checking and other code, shows what's going on:

void RetrieveRow(...)
{
    // All necessary environment, statement, describe, and define functions
    // have already been called; non-dynamic buffers have already been allocated
    retcode = OCIStmtFetch2(mystmt, fConnection->myerrhp, 1, OCI_DEFAULT, 0, OCI_DEFAULT);
    while (retcode == OCI_NEED_DATA)
    {
        // ...
        // ... Define the necessary arguments to OCIStmtGetPieceInfo() here ...
        // ...
        OCIStmtGetPieceInfo(mystmt, fConnection->myerrhp, (dvoid**)&define, &type, &inout, &iter, &idx, &piecep)

        // ...
        // ... Iteratively allocate and increase the buffer size for the required dynamic column here...
        // ...
        OCIStmtSetPieceInfo(define, OCI_HTYPE_DEFINE, fConnection->myerrhp, buf, alenp, piecep, indp, rcodep)

        // ... Call OCIStmtFetch2() as part of the dynamic loop to fetch the next piece
        retcode = OCIStmtFetch2(mystmt, fConnection->myerrhp, 1, OCI_DEFAULT, 0, OCI_DEFAULT);
    }
    // retcode is OCI_SUCCESS here when RetrieveRow() is called for the first row,
    // ... and all data in the first row is properly populated in the buffers.
    // But, when RetrieveRow() is called the second time, the above loop is entered,
    // ... the INTEGER, VARCHAR (a dynamic field), and FLOAT fields are correctly populated,
    // ... but the DATE field is corrupt, retcode is OCI_ERROR, and the error is ORA-03106.
    // ... Note that even with a dynamic callback used instead of a loop, the error is the same.
    // ... Note that when piecewise (dynamic) fetching is NOT used,
    // ... all rows are retrieved successfully and there is no error.
}

      

        
        
        
      

    

Note. As reflected in my name change, this issue does NOT occur when OCI and Oracle 11g are used. If the code hasn't changed FULLY, but includes the 11g OCI header files and loads the 11g OCI DLL while running the 11g Oracle servererver listener / instance, the code succeeds WITHOUT this error. It is only 10g in which the error occurs.

I would be happy if there was a link that clearly and reasonably identifies this as an OCI / Oracle bug in 10g. (I am convinced that this is the case.) However, I cannot find confirmation that this is an OCI / Oracle bug.