At 2:15 AM +0100 8/2/01, Tim Bunce wrote:
>On Mon, Jul 30, 2001 at 04:57:09PM -0400, Steven Schmidt wrote:
>> The following problem came up in porting EnsEMBL to Oracle:
>>
>> Level 9 DBI trace:
>> OCIStmtExecute(62c0ec,6363d0,62c310,0,0,0,0,0)=SUCCESS
>> OCIAttrGet(6363d0,4,ffbeebea,0,10,62c310)=SUCCESS
>> dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0)
>> <- execute= '0E0' at /usr/local/apache/perl/foo.pl line 34
>> >> fetchrow_array DISPATCH (DBI::st=HASH(0x381d1c) rc1/1 @1 g1
>> a0) at /usr/local/apache/perl/foo.pl line 35
>> -> fetchrow_array for DBD::Oracle::st
>> (DBI::st=HASH(0x381d1c)~0x384ecc)
>> dbd_st_fetch 4 fields...
>> OCIStmtFetch(6363d0,62c310,1,2,0)=SUCCESS
>> dbih_setup_fbav for 4 fields => 0x384c8c
>> dbd_st_fetch 4 fields SUCCESS
>> 0 (rc=0): '484'
>> OCILobGetLength(62c0ec,62c310,62a4d4,ffbee9dc)=SUCCESS
>>
>>
>>OCILobRead(62c0ec,62c310,62a4d4,ffbee9d8,1,782808,136351,0,0,0,1)=STIL
>>L_EXECUTING
>
>That's almost certainly an Oracle bug. DBD::Oracle doesn't enable non-blocking
>mode of the OCI so, as far as I know, the OCI should never return
>STILL_EXECUTING.
I'm sure I've seen this before... On a really old version of
DBD::Oracle. One of my selects was failing on a string greater than
140k... It was under linux, RH 5.1, DBD::Oracle < 0.96, DBI < 1.00.
I can't remember exactly what error I got, but upgrading DBD::Oracle
seemed to fix the problem.
Rob
>Talk to Oracle about it.
>
>No need to mention DBD::Oracle... just send them the trace after
>removing lines that don't match /\bOCI\w+\(/
>
>:-)
>
>Tim.
--
"A good magician never reveals his secret; the unbelievable trick
becomes simple and obvious once it is explained. So too with UNIX."
