Is the below the correct usage for finishing still active child
handles of a dbh?
foreach my $childh (@{$dbh->{ChildHandles}}) {
$childh->finish() if ($childh->{Type} eq 'st');
}
I'm getting an error when running the above code:
dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS
attribute probably not set right
Thanks
H
On Thu, Aug 24, 2006 at 09:47:56AM +0200, Henri Asseily wrote:
> Is the below the correct usage for finishing still active child
> handles of a dbh?
>
>
> foreach my $childh (@{$dbh->{ChildHandles}}) {
> $childh->finish() if ($childh->{Type} eq 'st');
> }
The children of a dbh will always be sth, but the test is harmless.
>
> I'm getting an error when running the above code:
>
> dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS attribute probably not set right
Looks like a bug (in the driver, I'd guess, but you don't say which)
because calling finish should never need to call dbih_setup_fbav.
But checking for Active will probably avoid the problem:
$_->finish for grep { $_->{Active} } @{$dbh->{ChildHandles}};
Tim.
Thanks, Tim.
One more question to the group:
If I "undef $dbh" when it is active and it has active (or inactive)
child handles, what happens exactly?
Is an actual $dbh->disconnect() made, and are the $sth's finished at
all? Is it DBD dependent?
Thanks in advance,
Henri.
On Aug 28, 2006, at 11:15 PM, Tim Bunce wrote:
> On Thu, Aug 24, 2006 at 09:47:56AM +0200, Henri Asseily wrote:
>> Is the below the correct usage for finishing still active child
>> handles of a dbh?
>>
>>
>> foreach my $childh (@{$dbh->{ChildHandles}}) {
>> $childh->finish() if ($childh->{Type} eq 'st');
>> }
>
> The children of a dbh will always be sth, but the test is harmless.
>>
>> I'm getting an error when running the above code:
>>
>> dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS
>> attribute probably not set right
>
> Looks like a bug (in the driver, I'd guess, but you don't say which)
> because calling finish should never need to call dbih_setup_fbav.
>
> But checking for Active will probably avoid the problem:
>
> $_->finish for grep { $_->{Active} } @{$dbh->{ChildHandles}};
>
> Tim.
Here's a little test:
#!/usr/bin/perl
use DBI;
my $dbh = DBI->connect('dbi:Sybase:server=DBA_SQL', '...', '...');
my $sth = $dbh->prepare("select * from histo..table_size where serverName =
'BPSREC5_SQL'");
$sth->execute;
DBI->trace(5);
undef $dbh;
This produces the following:
DBI 1.51-ithread default trace level set to 0x0/5 (pid 22393)
Note: perl is running without the recommended perl -w option
<> DESTROY(DBI::st=HASH(0x9d98514)) ignored for outer handle (inner
DBI::st=HASH(0x9d984fc) has ref cnt 1)
-> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x9d984fc)~INNER)
thr#9bdc008
syb_st_finish() -> ct_cancel(CS_CANCEL_ALL)
clear_sth_flags() -> resetting ACTIVE, moreResults, dyn_execed,
exec_done
clear_sth_flags() -> reset inUse flag
syb_st_destroy: called on 9d9abb8...
syb_st_destroy(): freeing imp_sth->statement
ct_cmd_drop() -> CS_COMMAND 9d9aa28
syb_st_destroy(): cmd dropped: 1
<- DESTROY= undef
dbih_clearcom 0x9d984fc (com 0x9d9abb8, type 3) done.
<> DESTROY(DBI::db=HASH(0x9d95b94)) ignored for outer handle (inner
DBI::db=HASH(0x9d96c18) has ref cnt 1)
-> DESTROY for DBD::Sybase::db (DBI::db=HASH(0x9d96c18)~INNER)
thr#9bdc008
syb_db_disconnect() -> ct_close()
<- DESTROY= undef
dbih_clearcom 0x9d96c18 (com 0x9d97838, type 2) done.
-- DBI::END
-> disconnect_all for DBD::Sybase::dr
(DBI::dr=HASH(0x9ceb734)~0x9d95ba0) thr#9bdc008
<- disconnect_all= 1 at /usr/lib/perl5/site_perl/5.8.6
/i386-linux-thread-multi/DBI.pm line 698 via /home/pepm01a/tmp/child.pl
line 0
! -> DESTROY in DBD::_::common for DBD::Sybase::dr
(DBI::dr=HASH(0x9d95ba0)~INNER) thr#9bdc008
! <- DESTROY= undef during global destruction
dbih_clearcom 0x9ceb734 (com 0x9cd1dd8, type 1) done.
! <> DESTROY for DBI::dr=HASH(0x9ceb734) ignored (inner handle gone)
As you see this calls the DESTROY for the sth (which cancels the query),
and then calls the DESTROY for the dbh (which closes the connection). There
is no special code in DBD::Sybase to handle this case AFAIK.
Michael
Extranet
henri@shopzilla.com - 29/08/2006 13:44
To: dbi-users
cc:
Subject: Re: finishing sth using Childhandles
Thanks, Tim.
One more question to the group:
If I "undef $dbh" when it is active and it has active (or inactive)
child handles, what happens exactly?
Is an actual $dbh->disconnect() made, and are the $sth's finished at
all? Is it DBD dependent?
Thanks in advance,
Henri.
On Aug 28, 2006, at 11:15 PM, Tim Bunce wrote:
> On Thu, Aug 24, 2006 at 09:47:56AM +0200, Henri Asseily wrote:
>> Is the below the correct usage for finishing still active child
>> handles of a dbh?
>>
>>
>> foreach my $childh (@{$dbh->{ChildHandles}}) {
>> $childh->finish() if ($childh->{Type} eq 'st');
>> }
>
> The children of a dbh will always be sth, but the test is harmless.
>>
>> I'm getting an error when running the above code:
>>
>> dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS
>> attribute probably not set right
>
> Looks like a bug (in the driver, I'd guess, but you don't say which)
> because calling finish should never need to call dbih_setup_fbav.
>
> But checking for Active will probably avoid the problem:
>
> $_->finish for grep { $_->{Active} } @{$dbh->{ChildHandles}};
>
> Tim.
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
On Aug 29, 2006, at 2:08 PM, michael.peppler@bnpparibas.com wrote:
>
> As you see this calls the DESTROY for the sth (which cancels the
> query),
> and then calls the DESTROY for the dbh (which closes the
> connection). There
> is no special code in DBD::Sybase to handle this case AFAIK.
>
Thanks, I didn't have easy access to a DBI-enabled machine today :-)
However, the dbh undef calls the sth DESTROY which calls the sth
finish(), and the sth finish can, in some cases, throw an error such
as the one I had that says :
dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS
attribute probably not set right
The "in some cases" above is after a signal interrupt, when the sth
is potentially a bad state.
So how do I clear the sth when I know it's in a bad state, without
calling finish() that expects the sth to be in a workable state?
H
Ah! I think I know what happens...
You probably have the syb_flush_finish attribute turned on - which means
that DBD::Sybase will try to fetch all the results that are pending for the
active sth.
I'm going to have to look at the code to see how that could be invalidated
(or fixed!)
Michael
Extranet
henri@shopzilla.com - 29/08/2006 15:56
To: dbi-users
cc:
Subject: Re: finishing sth using Childhandles
On Aug 29, 2006, at 2:08 PM, michael.peppler@bnpparibas.com wrote:
>
> As you see this calls the DESTROY for the sth (which cancels the
> query),
> and then calls the DESTROY for the dbh (which closes the
> connection). There
> is no special code in DBD::Sybase to handle this case AFAIK.
>
Thanks, I didn't have easy access to a DBI-enabled machine today :-)
However, the dbh undef calls the sth DESTROY which calls the sth
finish(), and the sth finish can, in some cases, throw an error such
as the one I had that says :
dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS
attribute probably not set right
The "in some cases" above is after a signal interrupt, when the sth
is potentially a bad state.
So how do I clear the sth when I know it's in a bad state, without
calling finish() that expects the sth to be in a workable state?
H
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
On Aug 29, 2006, at 4:29 PM, michael.peppler@bnpparibas.com wrote:
> Ah! I think I know what happens...
>
> You probably have the syb_flush_finish attribute turned on - which
> means
> that DBD::Sybase will try to fetch all the results that are pending
> for the
> active sth.
That's most certainly it! I also forgot about syb_flush_finish which
is a necessity in my environment.
> I'm going to have to look at the code to see how that could be
> invalidated
> (or fixed!)
Well I think there is a simple solution: right before undef'ing the
dbh or sth, I can update the dbh to turn off syb_flush_finish, which
is quite logical and should be done by the client (who else can know
better about a signal interrupt state?)
However, at that time the dbh may well be in a bad state since it's
right after a signal interrupt. But turning off syb_flush_finish is a
simple integer assignment to a dereference of imp_dbh, and it
shouldn't be an issue even after an interrupt. Below is the relevant
code:
if (kl == 16 && strEQ(key, "syb_flush_finish")) {
on = SvTRUE(valuesv);
if(on) {
imp_dbh->flushFinish = 1;
} else {
imp_dbh->flushFinish = 0;
}
return TRUE;
}
Thanks for the help, Michael.
Henri.
>
> Michael
>
>
>
>
> Extranet
> henri@shopzilla.com - 29/08/2006 15:56
>
> To: dbi-users
>
> cc:
>
>
> Subject: Re: finishing sth using Childhandles
>
>
>
>
> On Aug 29, 2006, at 2:08 PM, michael.peppler@bnpparibas.com wrote:
>
>>
>> As you see this calls the DESTROY for the sth (which cancels the
>> query),
>> and then calls the DESTROY for the dbh (which closes the
>> connection). There
>> is no special code in DBD::Sybase to handle this case AFAIK.
>>
>
> Thanks, I didn't have easy access to a DBI-enabled machine today :-)
> However, the dbh undef calls the sth DESTROY which calls the sth
> finish(), and the sth finish can, in some cases, throw an error such
> as the one I had that says :
> dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS
> attribute probably not set right
>
> The "in some cases" above is after a signal interrupt, when the sth
> is potentially a bad state.
> So how do I clear the sth when I know it's in a bad state, without
> calling finish() that expects the sth to be in a workable state?
>
> H
>
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
> ---------------------------------------------
>
> Ce message et toutes les pieces jointes (ci-apres le
> "message") sont etablis a l'intention exclusive de ses
> destinataires et sont confidentiels. Si vous recevez ce
> message par erreur, merci de le detruire et d'en avertir
> immediatement l'expediteur. Toute utilisation de ce
> message non conforme a sa destination, toute diffusion
> ou toute publication, totale ou partielle, est interdite, sauf
> autorisation expresse. L'internet ne permettant pas
> d'assurer l'integrite de ce message, BNP PARIBAS (et ses
> filiales) decline(nt) toute responsabilite au titre de ce
> message, dans l'hypothese ou il aurait ete modifie.
>