On 20/02/08 17:07, Martin Evans wrote:
Hi,
Just wondered if anyone else had seen this and if there are any opinions
on getting around it. I use DBIx::Log4perl (which I wrote to help debug
our DBI appication) and DBD::Oracle. New code added to our application
calls an oracle package function which returns a reference cursor and it
is bound in Perl like so:
my $sth2;
my $sth1 = $h->prepare(q{BEGIN ? := pkg.testfunc; END;});
$sth1->bind_param_inout(1, \$sth2, 0, { ora_type => ORA_RSET } );
as per DBD::Oracle pod. After $sth1->execute, $sth2 is a statement
handle but DBIx::Log4perl does not know about it and hence when it is
used it leads to errors in DBIx::Log4perl when it accesses private
attributes it usually stores in the statement handle (e.g. a Log4perl
log handle) which are not present. i.e., normally when the application
calls the prepare method, DBIx::Log4perl sees the returned statement
handle and does something like:
my $sth = $dbh->SUPER::prepare(@args);
$sth->{private_DBIx_Log4perl} = $log_handle if ($sth);
but DBIx::Log4perl did not see this magically returned statement handle.
These statement handles are presumably of the correct class.
All that is wrong with them is that DBIx::Log4perl has not
has a chance to initialise them. They have never been through
prepare or execute, but are nevertheless ready to fetch from.
One approach would be to modify all the fetch methods in
DBIx::Log4perl to expect uninitialised statement handles and
initialise on demand.
You will also have to cope with the fact that these handles
do not have useful Statement attributes.
--
Charles Jardine - Computing Service, University of Cambridge
[EMAIL PROTECTED] Tel: +44 1223 334506, Fax: +44 1223 334679
