Re: Apache::DBI Oracle LOB problem
This problem was fixed by upgrading Oracle to 8.1.7 -Steve Robert Landrum wrote: 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. -- Steven Schmidt snp.cshl.org www.gramene.org Cold Spring Harbor Laboratory 516-367-6977
Re: Apache::DBI Oracle LOB problem
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.
Re: Apache::DBI Oracle LOB problem
Mmm, haven't seen it, but we use LONG instead of CLOB as the datatype for the sequence. Is there any reason to use CLOB, and does using LONG make the problem disappear? Oracle doesn't want you to use LONG anymore. It's deprecated. Questions for Steven: Have you followed all the documentation on using LOBs in DBD::Oracle? Are you sure that LongReadLen is set high enough? - Perrin
