On Fri, Apr 02, 2004 at 12:16:06AM -0800, Jonathan Leffler wrote:
> Tim Bunce wrote:
> >Yes. There are two things I want to do:
> >
> >1. Specify a fairly short list of the specific SQLSTATE values that
> > I'd like drivers to support as a minimum.
>
> I'd prefer to have it called something else -- I'd say DBISTATE except
> that is overloading a term -- so that there is no confusion about
> whether this is what the DBMS said vs this is the mappe value produced
> by DBI or DBD::DBMS based on what the DBMS actually said. As long as
> there's a (standard!) way to get at what the DBMS actually said, I can
> stomach a short list of mappings - as long as there's a good generic
> "something went wrong" message.
I don't understand your concern here. The err and errstr values
will continue to be the native error and message strings returned
by the database.
All we're talking about here is setting state in those cases where
it's currently not set (for which the DBI always returns 'S1000').
So yes, there is and will always be a "way to get at what the DBMS
actually said". That won't change.
> >I'd expect to see existing code like:
> >
> > $dbh->do("INSERT ...");
> > if ($dbh->err =~ /duplicate/i) ...
> >
> >look like this:
> >
> > $dbh->do("INSERT ...");
> > if ($dbh->state eq '23505' or !$dbh->state && $dbh->err =~ /duplicate/i)
> > ...
>
> Hmmm; yes, if you're writing generic DBMS code, then the search is
> badly designed - or vulnerable to misreporting errors. There's always
> been a dichotomy between those using Perl to get at a specific (brand
> of) database and those using Perl to get at any brand of database.
> I'm primarily concerned about the former - maybe I should be more
> generous, but I don't want to impede the former from getting exactly
> what they need even if the latter also need help.
I agree.
> (One reason why AutoCommit still completely rankles with me!)
(I'll try to find the last time we discussed this. Or feel free to
start a new thread on dbi-dev with a summary of the issues.)
> >I wouldn't expect you to. But do you think you could manage 5 or 10?
>
> Maybe - which ones are you thinking of?
So far, only duplicate key violation and maybe table doesn't exist
and table already exists. That's about it.
Basically just a few errors that applications tend to need to
explicitly check for. Not a big deal.
> >References:
>
> http://www.ibm.com/software/data/informix/pubs/library/errors_ids94.pdf
I get "The document you requested does not exist on this server or cannot be served."
a 404 Not Found error.
Tim.
