[DB-SIG] Re: problems with DCOracle2 running on solaris 8 (oracle 8.1.6)

Kancianic, Jennifer C. (JKANCIAN) JKANCIAN@arinc.com
Wed, 12 Mar 2003 17:18:32 -0500


We were scrambling to find a solution to this same issue.  We are using
DCOracle2 1.2 on Linux 6.2, Oracle 8.1.7.

We finally tried setting the cursor.setPrefetch(None) after we created the
cursor object for the SQL statement that was having trouble.  This solved
the problem.  Not totally sure why, but we are glad it's working again.


Matt Kromer wrote:

I'm jumping into this thread a bit late but here goes.

I've had reports from a few sources that large queries would 
occasionally return NULL values instead of the columns they should when 
used on Linux rather than Solaris.

There may be a bizarre Oracle problem (which would be a first, wouldn't 
it?!) or a problem with the DCOracle2 code.

The only way for me to determine that for sure is to take a look at the 
trace logs DCOracle2 can generate.

You can either

    export DCO2TRACELOG=filename

which turns on continuous logging to a file or

    export DCO2TRACEFLAGS=255

which enables tracing but doesn't record to a file -- you can then do 
DCOracle2.traceback(format=1) to format the trace buffer.

The key thing I want to look at is whether or not there is a NULL answer 
being returned from the C layer, or if it's coming in from someplace else.

Andy Todd wrote:

>On Tue, Jan 28, 2003 at 12:15:58PM +0100, Molina Carron wrote: 
>>Right, this should help. 
>>My data (just a row): 
>>CD_CAMINO                      2 
>>CD_TRAMITE                      Registro 
>>CD_OPERACION               13800 
>>CONDICION                       ANIO_EXP_FISCALIA & '' # '' 
>>CD_ACCION                       X>X 
>>PARAMETRO1                    ANIO_EXP_FISCALIA 
>>PARAMETRO2                    x 
>>My problem: 
>>*I get different values for the field Parametro2 depending on how i access

>>to it: if my query is: 
>>    select * from rm_tra_acciones where cd_tramite=:p1 and cd_camino=:p2, 
>>(2, 'Registro',) 
>>it returns a lot of rows, and, when i move to the one above, and ask for
>>field Parametro2 it returns None (wrong!) 
>>*On the other hand, if my query is: 
>>select * from rm_tra_acciones where cd_tramite=:p1 and cd_camino=:p2 and 
>>(2, 'Registro',13800,) 
>>and ask my field, it returns x (correct!) 
>>*sqlplus works fine 
>>*No error messagges are returned 
>>*I get data from every query, but not every data is good 
>>My python code: 
>>def test(): 
>>    sql=[''' select * from rm_tra_acciones 
>>            where cd_tramite=:p1 and cd_camino=:p2 
>>        ''', 
>>        ''' select * from rm_tra_acciones 
>>            where cd_tramite=:p1 and cd_camino=:p2 and cd_operacion=:p3 
>>        '''] 
>>    params=[('Registro', 2,),('Registro', 2,13800,)] 
>>    import DCOracle2 
>>    cadenaConn='%s/%s@%s'% ('menores','menores','datos10k') 
>>    conn=DCOracle2.connect(cadenaConn) 
>>    print 'test1' 
>>    cur=conn.cursor() 
>>    cur.execute(sql[0],params[0]) 
>>    rs = cur.fetchall() 
>>    print rs[41] ##the row 
>>    print 'test2' 
>>    cur=conn.cursor() 
>>    cur.execute(sql[1],params[1]) 
>>    print cur.fetchall()[0] 
>>The results: 
>>>python -u etcPythonOracle.py 
>>[2L, 'Registro', 13800L, "ANIO_EXP_FISCALIA & '' # ''", 'X>X', 
>>'ANIO_EXP_FISCALIA', None, None, None] 
>>[2L, 'Registro', 13800L, "ANIO_EXP_FISCALIA & '' # ''", 'X>X', 
>>'ANIO_EXP_FISCALIA', 'x', None, None] 
>>>Exit code: 0 
>My first impression is that this is a data issue and nothing to do with the
db module or database. Are you sure that both of your queries are returning
the same row? It looks like they are not. 
>In test1 you are only restricting by cd_tramite and cd_camino but in test2
you add the cd_operacion column to the where clause. What happens if you
include the ROWID pseudo column in your results sets, are they the same? 
>The only other thing I can think of, and it is a long shot, is that you are
not comparing the same columns. Whilst performing a 'SELECT *' is more than
likely going to return the same columns in the same order each time you
execute a query there is absolutely no guarantee that this is true. I would
change your select clauses to ONLY return the columns of interest in this
particular case and eliminate this possibility even though it is fairly
unlikely to be the cause of your distress.