My current plan is to add a $h->{HandleEvent} = sub { ... }
hook that can be used for SUCCESS_WITH_INFO and other events the
driver may want to communicate back to an application.
Meanwhile I suggest that you add a $h->{ado_event} = sub { ... }
and and use that however you think best. Your experience can feed
back into the HandleEvent design.
Tim.
On Mon, Jan 12, 2004 at 03:59:07PM +0100, Steffen Goeldner wrote:
>
> I need an advice on how to deal with SUCCESS_WITH_INFO
> from a DBD writers point of view.
>
> If ADO places an error into it's error collection,
> this error may be one of 4 kinds (oledberr.h):
>
> 00 - Success
> 01 - Informational
> 10 - Warning
> 11 - Error
>
> A good example for the first case is given on dbi-users:
>
> <http://www.xray.mpe.mpg.de/mailing-lists/dbi/2003-12/msg00241.html>
>
> An ODBC function would return SQL_SUCCESS_WITH_INFO in
> such a case.
> Currently, DBD::ADO doesn't distinguish between these four
> kinds of errors, i.e. something like
>
> return $h->set_err( ... ) if $lastError;
>
> is always executed and the DBI user has to catch that error.
> Is this the intended DBI behavior?
> Alternatively, a DBD::ADO could ignore all but the last kind
> of error. But I'm not enthusiastic in throwing away such kind
> of information.
> There may be less drastic solutions, e.g. putting that
> information into special handle attributes.
>
> Any suggestions?
>
>
> Steffen
>
> P.S.: I'm aware that this topic is on DBI's ToDo list:
>
> The DBI needs some standard way to handle the
> 'success with info' concept
