|
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 |
