Re: Triggers Problem

In article <2aa.501.846%mpcbbs_at_ibase.org.br>, Carlos.Netto_at_ibase.org.br (Carlos Netto) writes:
|>
|> On 13 Oct 94 09:41am, Kevin Owens wrote to ALL:
|>
|> [stuff deleted]
|>
|> KO> solution at this point. We have implemented hundreds of business rules
|> KO> with Oracle triggers and here is how we solved this problem. First of
|> KO> all we always coded to handle multi-row insert/update/delete. We
|> KO> created PL/SQL tables in packages. The table is cleared in a
|> KO> before-statement trigger; populated with :new/:old correlation values
|> KO> at the row-level trigger (for each row of the multi-row) statment; then
|> KO> read the table and perform the original operation in the
|> KO> after-statement trigger. There are code examples in the October issue
|> KO> of DATABASE Programming and Design Magazine, Miller Freeman Press, try
|> KO> 800-444-4881 for .....try ...try 800-444-4881 for back issues.
|>
|> That's the way. Is there any conceptual reason to be this way? Is it just
|> consequence of Oracle's implementation of row-level triggers? Our work is
|> getting harder with this kind of limitation. Other RDBMS has no row-level
|> triggers, but once Oracle has it, what about a better implementation?!
|>

I think your response on Oracle not having enough time to provide a "complete" triggers solution is right. Other RDBMS (ie-DB2/400) do support row-level triggers without any silly restrictions like "mutating tables".

-- 
Kenton Milligan
DB2/400 Development 
kmill_at_rchland.vnet.ibm.com
(opinions stated are not necessarily those of my employer)