Re: Question on Insert Trigger

From: Serge Rielau <>
Date: Sat, 08 Mar 2008 07:34:00 -0500
Message-ID: <>

DA Morgan wrote:

> Serge Rielau wrote:

>> DA Morgan wrote:
>>> Serge Rielau wrote:
>>>> 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.


Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Received on Sat Mar 08 2008 - 06:34:00 CST

Original text of this message