[Mono-devel-list] Oracle ORA-24374: Fetch errors only on solaris but not linux

[Daniel Morgan]

As I mentioned earlier, it could be a byte-ordering problem.  65536 is 
not a valid statement type.

This is how OciStatementType is defined in System.Data.OracleClient.

namespace System.Data.OracleClient.Oci {
    internal enum OciStatementType {
        Default = 0x00,
        Select = 0x01,
        Update = 0x02,
        Delete = 0x03,
        Insert = 0x04,
        Create = 0x05,
        Drop = 0x06,
        Alter = 0x07,
        Begin = 0x08,
        Declare = 0x09
    }
}

OCI documentation says OCI_ATTR_STMT_TYPE is an ub2 which is an unsigned 
16-bit integer.

If you look at GetStatementType in StatementHandle, it uses 
GetAttributeInt32 to return an Int32.  Maybe, it should be returning an 
UInt16?  This could be done via GetAttributeUInt16 which is defined in 
OciHandle.

The OciStatementType could be defined as ushort.

    internal enum OciStatementType : ushort {

Can you try this and let me know?

Are you running Solaris on Sparc or x86?

Doug wrote:

>After some tracing and testing I am getting down to
>what is causing problems of mono on Solaris and using
>Oracle.  In the
>mcs/class/System.Data.OracleClient/System.Data.OracleClient
>directory, the file OracleCommand.cs has a private
>class called IsNonQuery.  This class is used to
>determine if a Statement being fed into the Oracle
>connection is a query or a DML statement.  The
>IsNonQuery is failing and ALWAYS returns false
>(because OciStatementType statementType =
>statementHandle.GetStatementType(); returns the number
> 65536 instead of the word Select?) This causes all
>statements to be treated like a DML statement even if
>it is a SELECT statement.  That causes Oracle to
>return an Error because a Select is treated different
>than DML.
>  If you are just using Selects to return data in
>mono, then a quick fix is just to always return false
>in the IsNonQuery function.  HOWEVER, if a DML
>statement such as Create table is used, there will be
>an Oracle Error returned with this approach.  Another
>quick fix approach would just be to scan the statement
>for Select and if it is found, then the IsNonQuery
>will return False, otherwise will return True.  
>   I am as yet unsure how to fix it correctly but if I
>figure it out, I will post a fix.  If anyone else can
>dig deeper and find the problem and the fix first,
>please let me know.  
>
>--- Daniel Morgan <danielmorgan at verizon.net> wrote:
>
>  
>
>>The problem might be with byte order - little-endian
>>vs. big-endian.  It 
>>works on Windows 2000/XP and Linux/x86.
>>
>>There is a bug for for OracleClient not working on
>>PPC (Mac OS X).  At 
>>the end of the bug, someone mentions it does not
>>work on Solaris either.
>>
>>http://bugzilla.ximian.com/show_bug.cgi?id=71318
>>
>>Patches are welcomed though.
>>
>>Also, if you take Mono's
>>System.Data.OracleClient.dll and run it on 
>>Microsoft .NET, it will fail to retrieve data. 
>>Maybe it does not 
>>marshall the data the way it should be.
>>
>>Doug wrote:
>>
>>    
>>
>>>We have installed and tested Mono 1.1.7 on both
>>>      
>>>
>>Linux
>>    
>>
>>>and Solaris and have windows forms working on both.
>>>      
>>>
>>>However the exact same code fails with a 
>>>  ERROR: ORA-24374: define not done before fetch
>>>      
>>>
>>or
>>    
>>
>>>execute and fetch
>>>  on solaris but works fine on the Linux machine. 
>>>Both machines have the same Oracle version and are
>>>connecting to the same database.  Has anyone else
>>>      
>>>
>>seen
>>    
>>
>>>this problem or have any ideas of how to resolve
>>>      
>>>
>>it?
>>    
>>