> Dean Arnold wrote: > >>A few months ago we had discussed on this list _standardizing_ error > >>handling for things like trying to insert duplicate records, but I kind > >>of dropped the ball - changing jobs and all didn't leave me enough time > >>to persue that standardization with members of this list. And since now > >>I don't use Perl in my new job, I don't have time to persue it at all. > >>Anyone else have time to revisit standardizing error handling for things > >>like "Trying to insert duplicate record"??? Basically all it involved > >>was putting together a list of common error conditions and finding the > >>corresponding ODBC error codes. > >>Hardy Merrill > > > > > > Er, isn't that what $h->state() is for ? In *theory*, state (aka SQLSTATE) > > codes should be fairly uniform across DBMS's (tho there's always a > > lot of platform specific state codes as well). However, I'm not certain > > that many drivers actually support $h->state(), or if they do, if they're > > conforming to the "standard" (presumably some SQL CLI std ?). > > If everybody adheres to that, then users can do a lookup of the > > appropriate SQLSTATE in the <insert SQL manual here> book, > > and key off the SQLSTATE value for disposition. > > I don't think it will fly. There are too many DBMS-specific problems > diagnosed by DBMS-specific values of SQLSTATE (or, in some cases, > DBMS-non-specific values - Informix has a tendency to set > SQLSTATE=IX000 - an Informix-specific error occurred; look at SQLCODE > to see what really went wrong) for it to be sensible to do the mapping. > > I, for one, have zero intention of going through 30,000 message codes > and mapping them to anything resembling a standard. > > -- > Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) > #include <disclaimer.h> > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ >
Is your concern about SQLSTATE, ODBC, or any mapping in general ? I think ODBC actually supports SQLSTATE (in fact, a quick Google for Informix SQLSTATE brought up the Informix ODBC manual w/ an error mapping index, albeit in a less than "codable" format) While I agree that trying to map every error code for every vendor into SQLSTATE is not feasible (esp. since the vendors themselves don't seem able to do it), there are usually a significant handful of SQLSTATEs that do have similar meaning across platforms (e.g., deadlock, connection failure, or, in the case of the subject issue, duplicate row insert). I guess I was just pointing out that a std. does exist, and theoretically, if drivers implemented it (and DBMS vendors adhered to it), then theres no real need for the chore H. Merrill suggested was needed. I certainly agree that trying to align all the error msgs from all vendors/drivers is a more herculean task than Mssr. Merrill may realize (in fact, if he ever manages to do it, he should seek a publisher and charge a hefty fee for the manuscript ...then he'll have lots of time to work on Perl/DBI ;^) Dean Arnold Presicient Corp. www.presicient.com
