Re: Triggers Problem

From: Kent Milligan <>
Date: 17 Oct 1994 01:27:35 GMT
Message-ID: <37sju7$>

In article <>, (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
(opinions stated are not necessarily those of my employer)
Received on Mon Oct 17 1994 - 02:27:35 CET

Original text of this message