Nevermind. That's now a "can't refetch lob from that kind of
statement" error. DBD::Oracle 1.15 has a new way of dealing with
LOB locators directly.
Tim.
On Fri, Jan 09, 2004 at 11:07:56PM +0000, Tim Bunce wrote:
> Can you, or someone, send me a test case that (ideally) doesn't
> include a function call to your own code but just uses PL/SQL LOB
> functions?
>
> If I get that soon I'll try to fix it for the 1.15 release or
> at least the 1.16 release.
>
> Tim.
>
> On Fri, May 02, 2003 at 10:03:23AM +0100, Chris Underhill wrote:
> > Hi,
> >
> > I have a function that returns a clob, the size of which depends on its
> > input parameters. I'm using code like:
> >
> > my $dbh=DBI->connect('dbi:Oracle:server',$user,$pass,{...})
> > $dbh->{LongReadLen}=1048576;
> > $dbh->{LongTruncOk}=1;
> > my $res;
> > my $sth=$dbh->prepare('BEGIN :res:=fn_foo(args...); END;');
> > $sth->bind_param_in_out(':res',\$res,1048576,{ora_type => ORA_CLOB});
> > $sth->execute;
> >
> > Unfortunately this results in a segfault, seemingly whatever I use for
> > the maxlen parameter of bind_param_inout, when the statement is
> > executed. If I miss out the maxlen parameter, then it works fine unless
> > the clob returned is >32k in size. In this case I get an ORA-6502 error.
> >
> > I have a workaround - executing select fn_foo(args...) from dual works
> > fine in all cases, but is obviously uglier, and won't work if there is
> > any dml in fn_foo. Any clues?
> >
> > This is with DBI-1.35 DBD-Oracle-1.14 on a Mandrake 9.1 box. It also
> > occurs on a Red Hat 7.3 box with DBI-1.19 + DBD-Oracle-1.14. Oracle
> > client stuff is 9.0.1, or 9.2 connecting to a Linux 9.2 server.
> >
> > TIA.
> >
> >
> > Chris.
> >
