On Tue, Apr 10, 2001 at 03:53:55PM -0400, Kenneth Graves wrote:
> Date: Tue, 10 Apr 2001 15:03:11 -0400
> From: Ranga Nathan <[EMAIL PROTECTED]>
>
> What would mysql return if:
>
> 1. an INSERT statement is incorrectly coded (expect undef)
> 2. correctly coded but due to duplicate row, no insertion possible (expect
> 0E0)
> 3. successful insert (expect 1)
>
> I find that in case 2 above, I am getting an undef instead of 0E0. Is this
> the expected behavior?
>
> I get the same (undef,undef,1) that you do (using $dbh->do).
>
> The DBI man page indicates "returns the number of rows affected or undef
> on error". Mysql appears to treat the duplicate primary key case as
> an error instead of as a correct statement affecting 0 rows.
> (Doing it from within the mysql utility returns "ERROR 1062", which
> would confirm that view.)
Oracle behaves in the same way. I figured this was the standard behavior.
ORA-00001: unique constraint (USER.CONSTRAINT_NAME) violated
When I want to catch this error, I generally do something like this:
$rc = $insert_sth->execute();
if (not $rc) {
if ($DBI::errstr =~ /unique constraint/) {
# special handling for unique constraint violation
} else {
# regular error handling
}
}
(RaiseError and PrintError should be off.)
As far as I know, DBI and DBD treat all database errors the same.
Ronald
