On Fri, May 30, 2003 at 03:28:34PM +0100, Brian McCauley wrote:
> Tim Bunce <[EMAIL PROTECTED]> writes:
> 
> > On Fri, May 30, 2003 at 10:56:35AM +0100, Brian McCauley wrote:
> > > "Richard Sames" <[EMAIL PROTECTED]> writes:
> > > 
> > > > The error message reads
> > > > 'DBD::Proxy::st execute_array failed: ArrayTupleStatus 
> > > > attribute must be an arrayref at 
> > > > /home/rjs/perl/WCL/Web/Binding.pm line 1058'
> > > 
> > > I just upgraded the development environment to DBI 1.37.
> > > 
> > > I'm sure the ArrayTupleStatus attribute is not intended to be
> > > mandatory but the new sanity check in execute_array() does not allow
> > > for this.
> > 
> > It's always a good idea to read the change notes...
> 
> >   Changed execute_array() return value from row count to executed
> >     tuple count, and now the ArrayTupleStatus attribute is mandatory.
> >     NOTE: That is an API definition change that may affect your code.
> 
> Yeah, OK.
> 
> Conversely it's always a good idea to minimise backwards
> incompatablity.
> 
> > > We don't need to get back the status on each insert because we are
> > > using DBI in RaiseError mode.
> > 
> > That only tells you something went wrong, not exactly what tuple
> > was affected.
> 
> So? If I've chosen to use DBI in RaiseError mode then this means that
> I'm not expecting anything to go wrong and I want to avoid the hassle
> of having to check the status of every do() or execute().  If
> something does go wrong then it's something unexpected so I'll just
> rollback the transaction and pass an error back up the stack.
> 
> > And for execute_array of delete/update statements you need
> > ArrayTupleStatus if you want to get the total row count.
> 
> But why should you be forced to specify the ArrayTupleStatus attribute
> if you don't want this information?  I have never found that I want
> the row count in any SQL statement.

I always check that deletes and updates that I expect to do something
actually have.

But I take your point. I'll ponder it (and suspect I'll change it).

Thanks.

Tim.

Reply via email to