DBD-AnyData, Handle cleared whilst still active...
DBD-AnyData, Handle cleared whilst still active...
am 10.10.2005 14:41:35 von Michael.Finken
------_=_NextPart_001_01C5CD97.F34EEC5E
Content-Type: text/plain
Hi....
I have a fresh compile of Perl 5.8.7, DBI-1.48, SQL-Statement 1.15,
AnyData-0.10 and DBD-AnyData-0.08 on AIX 5.2.
When running a script using DBD-AnyData, I always get the error message 'DBI
Handle cleared whilst still active.'
Here's the output of 'make test' for DBD-AnyData-0.08:
unix>make test
PERL_DL_NONLAZY=1 /usr/ud/util/perl5/bin/perl "-Iblib/lib" "-Iblib/arch"
test.pl
DBD::AnyData
CSV ... DBI handle 0x304f9dd8 cleared whilst still active at
test.pl line 73.
dbih_clearcom (sth 0x304f9dd8, com 0x30593778, imp DBD::AnyData::st):
FLAGS 0x182115: COMSET Active Warn PrintError PrintWarn
ShowErrorStatement
PARENT DBI::db=HASH(0x304ece34)
KIDS 0 (0 Active)
IMP_DATA undef
NUM_OF_FIELDS 3
NUM_OF_PARAMS 0
DBI handle 0x30593d48 cleared whilst still active at
/usr/ud/util/perl5/lib/site_perl/5.8.7/aix/DBI.pm line 1548.
dbih_clearcom (sth 0x30593d48, com 0x30597478, imp DBD::AnyData::st):
FLAGS 0x182115: COMSET Active Warn PrintError PrintWarn
ShowErrorStatement
PARENT DBI::db=HASH(0x304ece34)
KIDS 0 (0 Active)
IMP_DATA undef
NUM_OF_FIELDS 1
NUM_OF_PARAMS 0
DBI handle 0x304f9d24 cleared whilst still active at test.pl line 90.
dbih_clearcom (sth 0x304f9d24, com 0x30597478, imp DBD::AnyData::st):
FLAGS 0x182115: COMSET Active Warn PrintError PrintWarn
ShowErrorStatement
PARENT DBI::db=HASH(0x304ece34)
KIDS 0 (0 Active)
IMP_DATA undef
NUM_OF_FIELDS 1
NUM_OF_PARAMS 1
Perl5 and DBI were compiled with the IBM compiler (/usr/vac/bin/cc).
Is there anything I can do?
Thanks a lot,
Michael
P.S.: The same things happend on AIX 4.3.
------_=_NextPart_001_01C5CD97.F34EEC5E--
Re: DBD-AnyData, Handle cleared whilst still active...
am 14.10.2005 20:44:38 von jeff
> -----Original Message-----
> From: Michael.Finken@extern.oppenheim.de
> Subject: DBD-AnyData, Handle cleared whilst still active...
Sorry, this is a harmless bug. You can force install and everything shou=
ld work as expected. You'll get the "still active" warnings, but you can=
turn them off or ignore them. I'll fix the distro soon.
--
Jeff
Re: DBD-AnyData, Handle cleared whilst still active...
am 14.10.2005 21:00:28 von jseger
------=_Part_24441_31871288.1129316428154
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I'm getting the exact same warning in a script that uses DBD::ODBC. If I ru=
n
exactly the same code using DBD::Oracle the warning doesn't appear. I didn'=
t
do the install, so I can't tell you whether the warning appeared during the
install, but I expect not.
All of the rows got committed to the database that needed to, and all rows
that needed to be fetched were fetched.
Still harmless I hope?
On 10/14/05, jeff@vpservices.com wrote:
>
>
> > -----Original Message-----
> > From: Michael.Finken@extern.oppenheim.de
> > Subject: DBD-AnyData, Handle cleared whilst still active...
>
> Sorry, this is a harmless bug. You can force install and everything shoul=
d
> work as expected. You'll get the "still active" warnings, but you can tur=
n
> them off or ignore them. I'll fix the distro soon.
>
> --
> Jeff
>
>
>
--
It all comes down to a choice really.
You can get busy living, or get busy dying.
--Stephen King
------=_Part_24441_31871288.1129316428154--
Re: DBD-AnyData, Handle cleared whilst still active...
am 15.10.2005 22:14:10 von jeff
> -----Original Message-----
> From: Jeffrey Seger [mailto:jseger@gmail.com]
> Sent: Friday, October 14, 2005 07:00 PM
> To: dbi-users@perl.org
> Cc: jeff@vpservices.com
> Subject: Re: DBD-AnyData, Handle cleared whilst still active...
>
> I'm getting the exact same warning in a script that uses DBD::ODBC
My message about the bug was specific to DBD::AnyData and does *not* apply to DBD::ODBC or other DBDs.
The most common reason for this error (in general, not specific to AnyData) is forgetting to use finish() on a statement handle that hasn't been fully fetched so I'd suggest looking there.
--
Jeff
Fwd: DBD-AnyData, Handle cleared whilst still active...
am 16.10.2005 03:36:06 von jseger
------=_Part_34922_22243587.1129426566919
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
oops, meant to reply to the list.
---------- Forwarded message ----------
From: Jeffrey Seger
Date: Oct 15, 2005 9:34 PM
Subject: Re: DBD-AnyData, Handle cleared whilst still active...
To: "jeff@vpservices.com"
I haven't traced it all the way down because the code is workign as
designed, but putting the $sth->finish in didn't help. The result set was
also fully fetched and processed. The issue also went away when I switched
dsn's from Redbrick via ODBC to Oracle. Other than changing from
current_time to sysdate, the code was exactly the same.
If it matters, the DataBase Handles were created in child pids and lived
their entire lives in the child pid.
#just bcause this global is referenced in the function below.
my $TIMEFUNC =3D ($dsn =3D~ /ODBC/i) ? 'current_time' : (($dsn =3D~ /Oracle=
/i ) ?
'sysdate' : 'null');
sub set_status{
my $dbh =3D shift;
my $server =3D shift;
my $group =3D shift;
my $file =3D shift;
my $status =3D shift;
#this can return only one row as server,server_group,file_name is the PK on
this table.
my $check_sql =3D "select status from
logpull_hist
where server =3D ?
and server_group =3D ?
and file_name =3D ?";
my $insert_sql =3D "insert into
logpull_hist (status,status_time,server,server_group,file_name)
values(?,$TIMEFUNC,?,?,?)";
my $update_sql =3D "update logpull_hist
set status =3D ?, status_time =3D $TIMEFUNC
where server =3D ?
and server_group =3D ?
and file_name =3D ?";
$status =3D uc($status);
my $update =3D 0;
my $already_complete =3D 0;
my $sth =3D $dbh->prepare($check_sql);
$sth->execute( $server,$group,$file)|| die "unable to execute $check_sql";
while(my ($old_status) =3D $sth->fetchrow_array()){
$update =3D ($old_status =3D~ /F/i) ? 1 : 0;
$already_complete =3D ($old_status =3D~ /C/i) ? 1 : 0;
}
if ($already_complete){
$sth->finish();
return;
}
my $sql =3D (!$update && $status =3D~ /R/i) ? $insert_sql : $update_sql;
$sth =3D $dbh->prepare($sql) || die "unable to prepare $sql";
$sth->execute( $status,$server,$group,$file) || die "unable to execute
$sql";
$sth->finish();
}
On 10/15/05, jeff@vpservices.com < jeff@vpservices.com> wrote:
>
>
> > -----Original Message-----
> > From: Jeffrey Seger [mailto: jseger@gmail.com]
> > Sent: Friday, October 14, 2005 07:00 PM
> > To: dbi-users@perl.org
> > Cc: jeff@vpservices.com
> > Subject: Re: DBD-AnyData, Handle cleared whilst still active...
> >
> > I'm getting the exact same warning in a script that uses DBD::ODBC
>
> My message about the bug was specific to DBD::AnyData and does *not* appl=
y
> to DBD::ODBC or other DBDs.
>
> The most common reason for this error (in general, not specific to
> AnyData) is forgetting to use finish() on a statement handle that hasn't
> been fully fetched so I'd suggest looking there.
>
> --
> Jeff
>
>
>
--
It all comes down to a choice really.
You can get busy living, or get busy dying.
--Stephen King
--
It all comes down to a choice really.
You can get busy living, or get busy dying.
--Stephen King
------=_Part_34922_22243587.1129426566919--
Oracle DBD TO_DATE not working.
am 16.10.2005 22:24:35 von mdougher
I am having trouble using date operations in Oracle via DBI.
The following code fails to return any results.
$selectStatement.="SELECT s.NETWORK_NAME as NETWORK_NAME,";
$selectStatement.=" TO_CHAR(s.OUTAGE_START,'MM/DD/YYYY HH24:MI:SS') as
OUTAGE_START,";
$selectStatement.=" TO_CHAR(s.IMPLEMENTATION_DATE, 'MM/DD/YYYY HH24:MI:SS')
as IMPLEMENTATION_DATE";
$selectStatement.=" FROM SC.PFZOUTAGEM1 s";
$selectStatement.=" WHERE";
$selectStatement.=" (s.OUTAGE_START < TO_DATE(?,'dd-mm-yyyy hh24:mi:ss')";
$selectStatement.=" and s.OUTAGE_START >= TO_DATE(?,'dd-mm-yyyy hh24:mi:ss')";
$selectStatement.=")";
DBI->trace(2);
my $Qselect=$dbh->prepare($selectStatement);
$GMTIMEFUTURE='16-10-2005 16:48:00';
$GMTIME='16-10-2005 16:43:00';
$Qselect->execute($GMTIMEFUTURE, $GMTIME);
The following query in Toad Returns one row (I set the values so the query
would work).
SELECT s.NETWORK_NAME as NETWORK_NAME,
TO_CHAR(s.OUTAGE_START,'MM/DD/YYYY HH24:MI:SS') as OUTAGE_START,
TO_CHAR(s.IMPLEMENTATION_DATE, 'MM/DD/YYYY HH24:MI:SS') as
IMPLEMENTATION_DATE
FROM SC.PFZOUTAGEM1 s
WHERE (s.OUTAGE_START < TO_DATE('16-10-2005 16:48:00','dd-mm-yyyy
hh24:mi:ss')
and s.OUTAGE_START = TO_DATE('16-10-2005 16:43:00','dd-mm-yyyy hh24:mi:ss'))
Here is the trace output from DBI:
DBI 1.48-nothread default trace level set to 0x0/2 (pid 21322)
-> prepare for DBD::Oracle::db (DBI::db=HASH(0x5e2ce8)~0x626274 'SELECT
s.NETWORK_NAME as NETWORK_NAME, TO_CHAR(s.OUTAGE_START,
'MM/DD/YYYY HH24:MI:SS') as OUTAGE_START, TO_CHAR
(s.IMPLEMENTATION_DATE, 'MM/DD/YYYY HH24:MI:SS') as IMPLEMENTATION_DATE FROM
SC.PF
ZOUTAGEM1 s WHERE (s.OUTAGE_START < TO_DATE(?,'dd-mm-yyyy hh24:mi:ss') and
s.OUTAGE_START = TO_DATE(?,'dd-mm-yyyy hh24:mi:ss'))')
dbd_preparse scanned 2 distinct placeholders
fbh 1: 'NETWORK_NAME' NULLable, otype 1-> 5, dbsize 90/91, p90.s0
fbh 2: 'OUTAGE_START' NULLable, otype 1-> 5, dbsize 19/20, p19.s0
fbh 3: 'IMPLEMENTATION_DATE' NULLable, otype 1-> 5, dbsize
19/20, p19.s0
<- prepare= DBI::st=HASH(0x626d84) at InMaintenance.pl line 101
-> execute for DBD::Oracle::st (DBI::st=HASH(0x626d84)~0x626e98 '16-10-
2005 16:48:00' '16-10-2005 16:43:00')
bind :p1 <== '16-10-2005 16:48:00' (type 0)
bind :p1 <== '16-10-2005 16:48:00' (size 19/20/0, ptype 4, otype 1)
bind :p2 <== '16-10-2005 16:43:00' (type 0)
bind :p2 <== '16-10-2005 16:43:00' (size 19/20/0, ptype 4, otype 1)
dbd_st_execute SELECT (out0, lob0)...
dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0)
<- execute= '0E0' at InMaintenance.pl line 111
-> $DBI::err (*) FETCH from lasth=HASH
<- $DBI::err= undef
-> fetchrow_hashref for DBD::Oracle::st (DBI::st=HASH(0x626d84)~0x626e98)
1 -> FETCH for DBD::Oracle::st (DBI::st=HASH(0x626e98)~INNER 'NAME')
1 <- FETCH= [ 'NETWORK_NAME' 'OUTAGE_START' 'IMPLEMENTATION_DATE' ] at
InMaintenance.pl line 131
1 -> fetch for DBD::Oracle::st (DBI::st=HASH(0x626e98)~INNER)
1 <- fetch= undef at InMaintenance.pl line 131
<- fetchrow_hashref= undef at InMaintenance.pl line 131
-> DESTROY for DBD::Oracle::st (DBI::st=HASH(0x626e98)~INNER)
<- DESTROY= undef
-- DBI::END
-> disconnect_all for DBD::Oracle::dr (DBI::dr=HASH(0x242b90)~0x5e2c88)
<- disconnect_all= (not implemented) at DBI.pm line 677
! -> DESTROY for DBD::Oracle::db (DBI::db=HASH(0x626274)~INNER)
! <- DESTROY= undef during global destruction
! -> DESTROY in DBD::_::common for DBD::Oracle::dr (DBI::dr=HASH(0x5e2c88)
~INNER)
! <- DESTROY= undef during global destruction
Any advice would be helpful.
Matt Dougherty
mdougher@inch.com