Re: Question on Insert Trigger
From: Serge Rielau <srielau_at_ca.ibm.com>
Date: Fri, 07 Mar 2008 14:17:09 -0500
Message-ID: <63diluF25jcr1U1@mid.individual.net>
>> zigzagdna_at_yahoo.com wrote:
>> 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.
Date: Fri, 07 Mar 2008 14:17:09 -0500
Message-ID: <63diluF25jcr1U1@mid.individual.net>
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.
Cheers
Serge
-- Serge Rielau DB2 Solutions Development IBM Toronto LabReceived on Fri Mar 07 2008 - 13:17:09 CST