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

[Doug]

I added the change you suggested, remade the piece of
code, and retested.  However this didn't fix it.  I
was able to fix it by Changing OracleCommand.cs to
have the following in replacement for IsNonQuery

                private bool IsNonQuery
(OciStatementHandle statementHandle)    
                {                                     
                         
                        // assumes Prepare() has been
called prior to calling this function                 
                                                   
                                                      
                         
                if
(statementHandle.Command.CommandText.ToLower().Substring(0,6).IndexOf("select")!=0&
 
                    
statementHandle.Command.CommandText.ToLower().Substring(0,6).IndexOf("insert")!=0&
                                                      
  
statementHandle.Command.CommandText.ToLower().Substring(0,6).IndexOf("delete")!=0&
                                                      
  
statementHandle.Command.CommandText.ToLower().Substring(0,6).IndexOf("update")!=0&
                                                      
 
statementHandle.Command.CommandText.ToLower().Substring(0,5).IndexOf("merge")!=0)
                                                      
   
                  return true;                        
                         
                 else return false;                   
                         
                }
After doing this and remaking the
System.Data.OracleClient directory, the code works to
do Selects, executes (Both DML and non DML work), etc
to the Oracle Database.  The number of rows is
correctly returned, however, the actual values are
missing from the object structure brought back from
the reader.  Looking into this part now.

--- Daniel Morgan <danielmorgan at verizon.net> wrote:

> 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?
> >>    
> >>
> 
>