Re: Using a Trigger for a portion of a procedure

> During a large invoicing run, updates are made to
> an invoicing table within a Pro*C program; however,
> the invoicing table has an insert trigger on it
> which causes updates to be made to a separate table.
> This program takes several hours to execute, so we
> are looking at ways to optimize it.
>
> My question is: is there an advantage to 'encapsulating'
> some of the update processing (to the second table) within
> the trigger as described above, or are there inefficiencies
> or drawbacks to doing it this way? The updates to the
> 2nd table could have just as easily been written into the
> Pro*C module in the appropriate place.

I dislike triggers. They are, as Ian says resource intensive. They are also slow and more difficult to debug than other code. And for my money can't hold a candle to a good stored procedure or procedure in a package.

I'd have my Pro*C work through a database package and let it do whatever work needs to be done.

Daniel A. Morgan Received on Wed Feb 14 2001 - 00:30:10 CST