in reply to DB2 checking for an error on select

$sth->execute or die "Cant execute ($stmt) - $DBI::errstr\n";
This is the proper way to do it (checking the return value of execute) - not the one you quoted at the top (checking errstr).

I don't know if your problem is related but I remember a problem I once had with DB2 where a prepare using a non-existing column did not fail and it turned out that the DB2-client was configured in such a way that no data was sent to the server before the execute.

The DB2 client is highly configurable to minimize database-roundtrips and that sometimes means that errors are detected later then you would assume.

In your script it seems the only thing that fails is the first fetch and maybe this is again the first time data is sent to the server.

Try to talk to your admin or trace your session.

  • Comment on Re: DB2 checking for an error on select

Replies are listed 'Best First'.
Re^2: DB2 checking for an error on select
by dgarnier (Novice) on May 12, 2009 at 19:32 UTC
    I tried $sth->execute or die "Cant execute ($stmt) - $DBI::errstr\n"; but the or condition is not reached even thought the execute failed due to the table being offline. There are conditions where I would not find any data and that is OK, but if I don't find data due to the table not being available that is a problem. So I tried checking the fetch status 
    $status = $sth->execute;
print "Status = $status\n"; # the RC is always -1  weather the execute
+ worked or not

my $col1;
$sth->bind_col(1,\$col1);
while ($sth->fetch || die "Cant fetch data - $DBI::errstr\n") { 
    print "ID: $col1\n";
}

    [download]
    The problem with this is that when fetch runs out of a data to return it hit the || and dies, or if not data was found the script then dies.
[reply]
[d/l]
[select]
      I tried $sth->execute or die "Cant execute ($stmt) - $DBI::errstr\n"; but the or condition is not reached even thought the execute failed
      I think that the execute does not fail (even though it should because the table is offline) therefore the die is not reached.

      The reason the execute does not fail could be (I've seen it happen) that your client is configured in such a way that no data is sent to server (where the error would be detected).

      Probably your client sends the first packet to the server when you do the fetch, so you should check for errors there.

      To verify this theory try to tcpdump your session and check where the actual conversation between your client and the server occurs.

[reply]
        lets assume that the fetch is the first time I hare back from the server. How can I test for a fetch error? Keep in mind I am ok with 0 records returned, but no data found due to the table being off line is a problem
[reply]

In Section Seekers of Perl Wisdom