Re: Using a Trigger for a portion of a procedure

I've found that triggers are quite resource-intensive, and are therefore perfectly OK for tables where the updates are from an online process, but cause a significant loss in performance on batch updates. My bet is to put the logic for updating your secondary in the Pro*C app.

"GHouck" <hksys_at_teleport.com> wrote in message news:3A88E0E9.1B7_at_teleport.com...
> 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.
>
> Thanks,
>
> Geoff Houck
> systems hk
> hksys_at_teleport.com
> http://www.teleport.com/~hksys
Received on Tue Feb 13 2001 - 02:03:46 CST