> Thanks to several for pointing out the answer. I had indeed read
> the fine manual, but I conceptually missed the fact that RaiseError
> could apply to statement handles, and not just database handles.
> I can see the utility in that now, but I can also see much utility
> in having a connection scope RaiseError. I want to do this:
>
> eval {
> $dbh->{RaiseError} = 1;
> $sth1->execute;
> $sth2->execute;
> $sth3->execute;
> $sth4->execute;
> $sth5->execute;
> };
>
> Instead of:
>
> eval {
> $sth1->{RaiseError} = 1;
> $sth1->execute;
> $sth2->{RaiseError} = 1;
> $sth2->execute;
> $sth3->{RaiseError} = 1;
> $sth3->execute;
> $sth4->{RaiseError} = 1;
> $sth4->execute;
> $sth5->{RaiseError} = 1;
> $sth5->execute;
> };
>
> which is what I now realize I have to do if I don't know the
> RaiseError status of the statement handles. It seems to me
> that most of the code-neatness value that I often see cited
> for RaiseError and eval blocks is lost. In fact, individual die's
> look pretty attractive again:
>
> eval {
> $sth1->execute or die $DBI::err;
> $sth2->execute or die $DBI::err;
> $sth3->execute or die $DBI::err;
> $sth4->execute or die $DBI::err;
> $sth5->execute or die $DBI::err;
> };
Just set $dbh->{RaiseError} = 1 prior to the prepare()s. You can turn it
off right after them if you want. I hadn't noticed this characteristic
either because my normal habit is to turn it on immediately after
connecting.
--
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.
