Re: Question on Insert Trigger
From: Serge Rielau <srielau_at_ca.ibm.com>
Date: Sat, 08 Mar 2008 07:34:00 -0500
Message-ID: <63ffe1F27l50bU1@mid.individual.net>
>> DA Morgan wrote:
>> I think the OP made it clear that your proposal works for his overly
>> simplified example, but not the complex real world issue he has.
>> I am in no position to judge how complex is too complex for a check
>> constraint and whether his (not revealed) logic applies.
> Until the OP posts a single business rule that can't be handled with > a constraint ... that's my answer and I'm sticking with it. <g> Fair enough. Hypothetically: If the business rule depends on data in some table or a package variable (any sort of "external to the row" data), can it still be written as a constraint? Presumably VPD cannot "ignore" input data, so it isn't applicable here I guess.
Date: Sat, 08 Mar 2008 07:34:00 -0500
Message-ID: <63ffe1F27l50bU1@mid.individual.net>
DA Morgan wrote:
> Serge Rielau wrote:
>> DA Morgan wrote:
>>> Serge Rielau wrote: >>>> zigzagdna_at_yahoo.com wrote: >>>>> Thanks to all. not null in my code was just an example. My filtering >>>>> logic is lot more complex and cannot implemented through a costraint. >>>>> What I am asking is there a way to do filtering in the trigger if it >>>>> cannot be done using EXCEPTIONS INTO statement. >>>> Can you squeeze in a view? I.e. rename the table, create select-* >>>> view over the renamed table using the original table name. >>>> Then create an INSTEAD OF TRIGGER on the view to intercept the rows >>>> you don't like. You can ignore them, save them away, or patch them up. >>> Another person trying to put massive overhead where a simple >>> constraint would suffice: Why?
>> I think the OP made it clear that your proposal works for his overly
>> simplified example, but not the complex real world issue he has.
>> I am in no position to judge how complex is too complex for a check
>> constraint and whether his (not revealed) logic applies.
> Until the OP posts a single business rule that can't be handled with > a constraint ... that's my answer and I'm sticking with it. <g> Fair enough. Hypothetically: If the business rule depends on data in some table or a package variable (any sort of "external to the row" data), can it still be written as a constraint? Presumably VPD cannot "ignore" input data, so it isn't applicable here I guess.
Cheers
Serge
-- Serge Rielau DB2 Solutions Development IBM Toronto LabReceived on Sat Mar 08 2008 - 06:34:00 CST