Tim Bunce [EMAIL PROTECTED] wrote: > On Mon, Sep 29, 2003 at 10:19:46PM +0100, Andy Hassall wrote: > > > > > > 23000 Integrity constraint violation SQLBulkOperations > > > SQLExecDirect > > > SQLExecute > > > SQLParamData > > > SQLSetpos > > > > > > 40002 Integrity constraint violation SQLEndTrans > > > > 23000 and 40002 appear to match, but do they cover all constraints (primary > > key, unique, check, and foreign key). > > > > It looks like the difference between 23000 and 40002 is that 23000 is the > > result of a constraint violation, but 40002 is a constraint violation and > > the database has forced a rollback (i.e. you tried to commit violating data > > [so you must have had constraints deferred], so it rolls back instead). > > Yes. (Though I can't see why they bothered to add an extra code for > it when 23000 would have been fine.) > > > Seems a bit of a mess :-( > > Fun isn't it :) > > I don't see a big problem with code that's trying to be very > portable having to check for a small number of specific codes > (23000, 40002, 72000 etc) > > That's still a much better situation than trying to match error > strings. > > Most apps don't need that level or portability and could just use > the relevant code for their database.
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? 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? Thanks. Hardy Merrill
