Dave,
Thanks for your input. I am not sure the issue has much to do with the
DBI->trace(x), I get core dump regardles of this setting.
I have played a bit more, and manged to get the script to continue
execution through eval { $dbh->execute() };, however if the condition is
triggered it appears to leave some nasty stuff back in DBI/DBD, because
it will then dump core on the second pass through the same code
irrespective of 'eval'...
I am not sure if the difference in operating systems is significant
(Solaris vs. WinNt)?
The ORA-24338 from OCIAttrGet appears to suggest that DBD is trying to
do a describe on a parameter that for some reason Oracle thinks is not
there:
oerr ORA 24338
24338, 00000, "statement handle not executed"
// *Cause: A fetch or describe was attempted before executing a
// statement handle.
// *Action: Execute a statement and then fetch or describe the data.
Below is first the correct execution and then failed execution DBI
trace. Not sure what is going on, but in the latter case, dbd_st_execute
returns happily, but the dbd_describe that comes immeditely after is
totally rejected by Oracle.
I tried tracing the execution through DBI and DBD code but it is much
too convoluted for me. I was hoping someone with more understanding
(hint for developers :-) might realise quickly where the issue is.
Srdjan
========= SUCCESSFULL EXECUTION
====================================================================
-> execute for DBD::Oracle::st (DBI::st=HASH(0x28b8f4)~0x281690)
dbd_st_execute BEGIN (out2, lob0)...
bind :p3 - allocating new sth...
<- FETCH= 'DBD::Oracle::db' ('ImplementorClass' from cache) at
DBI.pm line 1001 via /export/home/c828764/CPAN/DBI_Driver/DBI_Driver.pl
line 328
New DBI::st (for DBD::Oracle::st, parent=DBI::db=HASH(0x28b8c4),
id=)
dbih_setup_handle(DBI::st=HASH(0x28b8dc)=>DBI::st=HASH(0x28169c),
DBD::Oracle::st, 28b8d0, Null!)
dbih_make_com(DBI::db=HASH(0x28b840), DBD::Oracle::st, 208) thr#0
bind :p3 - allocated DBI::st=HASH(0x28b8dc)...
with :p1 = '' (len 0(0)/28, indp 0, otype 1, ptype 6)
in ':p1' [0,0]: len 0, ind 0
in ':p2' [0,0]: len 2, ind 0
out ':p1' [0,0]: alen 29, piece 0
dbd_st_execute BEGIN returned (SUCCESS, rpc1, fn34, out2)
bind :p3 - initialising new DBI::st=HASH(0x28b8dc) for cursor
0x24c5f0...
dbd_describe SELECT (implicit, lb 80)...
fbh 1: 'COL2' NULLable, otype 1-> 5, dbsize 10/11, p10.s0
fbh 2: 'COL3' NULLable, otype 1-> 5, dbsize 10/11, p10.s0
dbd_describe'd 2 columns (row bytes: 20 max, 20 est avg, cache: 384)
out :p1 = '0' (arcode 0, ind 0, len 1)
<- execute= 1 at DBI_Driver.pl line 328 via
/export/home/c828764/CPAN/DBI_Driver/DBI_Driver.pl line 327
======== NOT QUITE AS SUCCESSFUL EXECUTION
=========================================================
-> execute for DBD::Oracle::st (DBI::st=HASH(0x28bad4)~0x28baa4)
dbd_st_execute BEGIN (out2, lob0)...
bind :p3 - allocating new sth...
<- FETCH= 'DBD::Oracle::db' ('ImplementorClass' from cache) at
DBI.pm line 1001 via /export/home/c828764/CPAN/DBI_Driver/DBI_Driver.pl
line 328
New DBI::st (for DBD::Oracle::st, parent=DBI::db=HASH(0x28b8c4),
id=)
dbih_setup_handle(DBI::st=HASH(0x28bbdc)=>DBI::st=HASH(0x28ba08),
DBD::Oracle::st, 28b8d0, Null!)
dbih_make_com(DBI::db=HASH(0x28b840), DBD::Oracle::st, 208) thr#0
<> DESTROY ignored for outer handle DBI::st=HASH(0x28b8dc) (inner
DBI::st=HASH(0x28169c))
-> DESTROY for DBD::Oracle::st (DBI::st=HASH(0x28169c)~INNER)
<- DESTROY= undef at DBI_Driver.pl line 328
bind :p3 - allocated DBI::st=HASH(0x28bbdc)...
with :p1 = '' (len 0(0)/28, indp 0, otype 1, ptype 6)
in ':p1' [0,0]: len 0, ind 0
in ':p2' [0,0]: len 3, ind 0
out ':p1' [0,0]: alen 29, piece 0
dbd_st_execute BEGIN returned (SUCCESS, rpc1, fn34, out2)
bind :p3 - initialising new DBI::st=HASH(0x28bbdc) for cursor
0x24c6e0...
dbd_describe SELECT (implicit, lb 80)...
!! ERROR: 24338 'ORA-24338: statement handle not executed (DBD
ERROR: OCIAttrGet OCI_ATTR_PARAM_COUNT)'
<- execute= undef at DBI_Driver.pl line 328 via
/export/home/c828764/CPAN/DBI_Driver/DBI_Driver.pl line 327
=================== END OF DUMP
======================================================================
-----Original Message-----
From: Dave K [mailto:[EMAIL PROTECTED]]
Sent: Sunday, 16 February 2003 5:05 PM
To: [EMAIL PROTECTED]
Subject: Re: DBI/DBD Oracle dumps core on Solaris 8 when reference
cursor returned untouched
Srdjan,
> Hi,
Howdy,
> Versions:
> Perl: 5.6.1
Mine is 5.8
> DBI: 1.32
> DBD-Oracle: 1.12
Mine are similar
> Operating System: Solaris 5.8
WinNt
> Oracle version: 8.1.7
I am 8.1.5
> Description:
> procedure, the program dumps core.
No core dump here unless DBI->trace(n) is set with 'n' > 1
> Note that the execution is successful also if the cursor statement did
> not have any rows returned. The program fails ONLY if the cursor is
> untouched.
I made the table and stored code - thanks for posting completely!
> use DBI qw(:sql_types); # Perl DBI Database
> DBI->trace(5);
I used DBI->trace(1);
and it (finally) did not dump core. I wonder if a core dump is a
'feature' for trace >1
>
> $sth = $dbh->prepare('BEGIN :1 := BUG_PACKAGE.BUG_FUNCTION(:2,:3);
I don't think it actualy matters but I bound as:
? := BUG_PACKAGE.BUG_FUNCTION(?, ?);
> $sth->bind_param_inout(1, \$ErrCode, 0)
> while(@row = $csr->fetchrow_array) {
> print (join(',', @row)."\n");
> }
>
> $sth->finish
> || die "Cannot finish the execution: ".$DBI::errstr."\n";
I included:
$csr->finish || die "Cannot finish the execution: ".$DBI::errstr."\n";
beacuse (after taming the seg fault) dbi complained about the open
handle
> $dbh->disconnect
> || warn "Database disconnect failed: $DBI::errstr\n";
>
> == failure.log
>
========================================================================
> !! ERROR: 24338 'ORA-24338: statement handle not executed (DBD
I believe this is the ref cursor not executing
> ERROR: OCIAttrGet OCI_ATTR_PARAM_COUNT)'
> <- execute= undef at ./bug.pl line 40
> DBD::Oracle::st execute failed: ORA-24338: statement handle not
> executed
I believe this is the focus here - the ref cursor is not executed
(because of the exception you raise in your code) I understand you do
not want to alter the stored code, so try setting trace to 1 and see if
it is better behaved. HTH David
