in reply to Re^2: DB2 checking for an error on select
in thread DB2 checking for an error on 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.

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

Replies are listed 'Best First'.
Re^4: DB2 checking for an error on select
by dgarnier (Novice) on May 13, 2009 at 15:21 UTC
    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]
      fetch returns undef if either there are no more rows or when en error occurs.

      You can distinguish these cases by checking $sth-err.

      So in code you can do something like this:

      while( defined $sth->fetch) {
 # do something with fetched data
}
if($sth->err) {
# handle error
}
else {
# no more data
}

      [download]
[reply]
[d/l]
        Thanks that did the trick
[reply]

In Section Seekers of Perl Wisdom