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