At 08:40 AM 21/04/2003 +0930, you wrote:

>Helen Borrie wrote:
> >
> > At 08:02 AM 21/04/2003 +0930, you wrote:
> > >When a certain table is updated, it triggers a cascade of updates in
> > >other tables, many of whose fields might not satisfy their CHECK
> > >constraints.
> > >
> > >How is one to distinguish between these so that the user can be
> > >presented with meaningful information?
> > >
> > >E.g. Field "Amount Remaining" in Table "Feed Inventory" has become
> > >negative.
> >
> > You can create exceptions and use these in your triggers to return a
> > "meaningful" message to the client. For example,
> >
> > create exception balance_negative ' "Amount Remaining" in Table "Feed
> > Inventory" has become
> > negative.'
> >
> > (I haven't done a character count on this but the message string does have
> > a pretty short limit, I think about 70 characters...an incentive for
> > writing tight messages :-) ))
> >
>
>Table T3:
> F3a INTEGER CHECK(F2 >= 0)
> F3b INTEGER CHECK(F3 >= 0)
>
>Table T2: AU:
> Update T3.F3a = -F2 // fails CHECK constraint here as -F2 = -56
> Update T3.F3b = -F2
>
>Table T1: AU:
> Update T4.F4 = 60 // some other table that doesn't cause exception
> Update T2.F2 = 56
> Update T5.F5 = 68 // some other table that doesn't cause exception
>
>When T1 is updated, INTEG_63 is violated: F3a >= 0.
>
>Where in this do I specify the exception, as I dont' know what the
>reason for the exception is in the AU of table T1?

Raymond,
The first unhandled exception will stop the flow and return *that*
exception to the client. As long as you don't "swallow" the exception
higher in the call chain, you can localise the exception in the trigger
where it occurs.

heLen