Methods for handling database errors

[eluser]carvingCode[/eluser]
Wondering what methods you are using to handle database errors? CI passes them off to the 'errors->error_db.php' page just fine. But, beyond that, has anyone written a library, etc. which offers more control?

A specific case I have is in trapping for a duplicate entry key. Again, CI traps and stops processing at that point just fine. But, how would I trap and display my own message and/or redirect?

TIA (rather new to CI)

[eluser]carvingCode[/eluser]
Thinking about this: Should I add the db error trapping in the ‘errors->error_db.php’ page? Does this always, automatically, get called when a db error occurs? (Is there an article on this somewhere?)

TIA

[eluser]Dan Horrigan[/eluser]
Easiest way is going to be to make a "check_if_exists()" function in your model, then query the DB to see if that key already exists. To do what you want, you would have to override the DB classes and suck, which is not supported. You would have to modify he core libraries...which is not fun (or a good idea).

As long as you have your private key/indexes setup correctly a simple "select `id` from table where `id`=34" is not going to add much over head at all to your app (maybe a couple hundredths of a second).

Dan

[eluser]carvingCode[/eluser]
Yes, simple solutions are best. Thanks!

[eluser]carvingCode[/eluser]
Follow up:

I added a SELECT statement prior to INSERT to check for the occurrence of duplicate key(s). In my tests using approximately 60 records with 20 duplicates, all worked fine. No duplicates were inserted and no errors.

When I bumped up my test to a more real world example of 10K records (this portion of the app converts a CSV dump of an existing DB), the program errors outs with a duplicate KEY error at approx. record 8200. There were no duplicates prior to this, so it found the first dupe.

Any idea what would cause this? Is MySQL being overrun?

Any way to solve this, aside from pre-cleaning the file-to-be-imported?

TIA

[eluser]carvingCode[/eluser]
To solve my problems, I use INSERT IGNORE. Still not sure why the previous attempt (using SELECT statement prior to INSERT to check for the occurrence of duplicate key(s)) worked for small test samples and not large.