Tim Bunce wrote:
> On Tue, Sep 30, 2003 at 08:57:35AM -0400, Hardy Merrill wrote:
>>
>> So I'm still not clear - for this "failed trying to insert
>> duplicate key" situation, is 23000 (Integrity Constraint
>> Violation) going to be the choice?
>
> Yes. (Except for systems that support deferred constraints
> in which case the commit() could set state to 40002.)
>
>> My thought was that we'd
>> somehow want to know specifically that the violation is caused
>> by an attempt to insert a duplicate key, but 23000 is a
>> "generic" constraint violation error. Is a generic constraint
>> violation error what we want for this?
>
> It's all the standard gives you.
>
> If you need more details there's always $h->errstr ...
If that's all the standard gives you, then is it much use?
I think I agree with Ronald; having some standardised DBI errors defined,
which the driver maps its native values to would be useful.
Being able to write something like:
$sth_insert->execute(1,2,3);
if ($dbh->err) {
if ($dbh->dbi_error_code == DBI::ERROR_PRIMARY_KEY_VIOLATION) {
// do an update instead
}
if ($dbh->dbi_error_code ==
DBI::ERROR_FOREIGN_KEY_VIOLATION_PARENT_NOT_FOUND) {
// add necessary parent records, retry insert
}
}
... and not worry about which DBD it's using could be useful, certainly
neat anyway (I can never remember the numeric codes to check for when
switching between Oracle and MySQL).
What would need mapping? An initial list could be:
Primary key violation
Unique key violation
Not null constraint violation
Check constraint violation
Foreign key violation - parent not found on insert
Foreign key violation - child records exist on update or delete
--
Andy Hassall ([EMAIL PROTECTED]) icq(5747695) (http://www.andyh.co.uk)
Space: disk usage analysis tool (http://www.andyhsoftware.co.uk/space)
