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;
};
Thanks again all,
Mark
> -----Original Message-----
> From: Stephen Clouse [mailto:stephenc@;theiqgroup.com]
> Sent: Wednesday, October 23, 2002 9:56 PM
> To: Mark Dedlow
> Cc: Dbi-Users
> Subject: Re: RaiseError sticks with statement handle??
>
>
> On Wed, Oct 23, 2002 at 08:05:42PM -0700, Mark Dedlow wrote:
> >
> > RaiseError appears to be saved per statement handle and not
> changeable for
> > the execution of a given statement once the statement has been prepared.
>
> Which is exactly as it's documented in the Fine Manual:
>
> ATTRIBUTES COMMON TO ALL HANDLES
> These attributes are common to all types of DBI handles.
>
> Some attributes are inherited by child handles. That is,
> the value of
> an inherited attribute in a newly created statement handle
> is the same
> as the value in the parent database handle. Changes to
> attributes in
> the new statement handle do not affect the parent database
> handle and
> changes to the database handle do not affect existing
> statement han‐
> dles, only future ones.
>
> --
> Stephen Clouse <[EMAIL PROTECTED]>
> Senior Programmer, IQ Coordinator Project Lead
> The IQ Group, Inc. <http://www.theiqgroup.com/>
>