That's the solution we're implementing, but would rather be able to handle specific database exceptions with the right database exception handler, not the generic one. Sadly, those specific db exception handlers don't exist, and we'll have to inspect the error messages to handle them properly.

So you need to do it manually as Dorine said and validate if is possible to execute what you are trying to change.

Hi Dorine, 

Was afraid that would be our only recourse, but we'll still have to go that way for some cases. 

We can't inspect every referenced table to check all the FK's to see if we can safely delete a value; handling the exception is the only reasonably feasible solution so far... 

So yes, I can see 2 reasons not to check everything : - the amount of extra code to write and maintain

- the performance penalty of all those checks being executed on every update.

If you have the budget to make a nice generic solution, I could imagine some hybrid approach where you let the database exception go off, and only in the exception handler execute the checks to avoid performance penalty in the happy flow.  And make use of the metamodel to execute the validations instead of coding them out, to avoid the burden of coding and maintaining the validations.

Dorine