Richard Huxton wrote: > I'm no guru myself... Don't underestimate yourself, after all you found the code where it goes wrong > Looks OK to me, except you'll not get any error message on the last row > - the insert will be called after the fetch. I do get an error message on the last row (assuming that it caused an error of course) There are [number of rows to fetch] + 1 fetches done by execute for fetch As the POD says: "The execute_for_fetch() method calls $fetch_tuple_sub ... until it returns a false value" So I get the error caused by the last record when execute_for_fetch fetches again and sees that there's nothing more to fetch. >What happens if you change the code to take a copy of sth->errstr too: Nothing. Same result. Which made me wonder why they take a copy of the error code anyway. So I dropped that replacing my $err = $sth->err; push @$tuple_status, [ $err, $errstr_cache{$err} ||= $sth->errstr, $sth->state ]; by push @$tuple_status, [ $sth->err, $errstr_cache{$err} ||= $sth->errstr, That gave me the same (but still unexpected) result.
Martijn van Oosterhout wrote: > The reference to erstr_cache seems to infer that the code assumes there > can be only one error string for any particular. Looking at the code I > can't work out why that variable even exists. And he was right! There lies the real problem. It seems to me like a (faulty) way to try to return each different error message only once. But that wouldn't be the behaviour as described in the POD. So finally I replaced my $err = $sth->err; push @$tuple_status, [ $err, $errstr_cache{$err} ||= $sth->errstr, $sth->state ]; by push @$tuple_status, [ $sth->err, $sth->errstr, $sth->state ]; That gives the result I would expect when reading the POD Thanks to both of you for solving this problem! Bart