withtape (AT) gmail (DOT) com wrote:
Quote:
Bill,
My concern about the possibility of changing the underlying database
structure is really secondary. My primary nag is the need to write
error handling without using the database engine, when it is so plain
that engine implementors could throw something meaningful. The engine
must know what the constraint was and exactly how it failed when it
throws the error; why does it not share this information?
Is there a coding framework that abstracts this? |
Ours does, among other things.
We put all constraints into a plaintext file and then have a builder create
the database and write triggers that enforce the constraints.
When a constraint fails, be it a PK or FK, or something like a credit limit,
the trigger stores a string and continues processing. When processing is
complete it returns all errors as a semicolon-delimited list. Our web
layer then breaks these up and reports them in HTML, as in "GL Batch is
closed, cannot modify" or "There is already a customer with code=WITHTAPE".
I would not be surprised if the entire framework is more than you had in
mind for what you want, but it may prove helpful to review how it does
these things:
http://docs.secdat.com
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)