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
