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

Reply via email to