Re: Multiple "before insert" triggers on a table?

"Rauf Sarwar" <rs_arwar_at_hotmail.com> wrote in message news:92eeeff0.0304231112.65283652_at_posting.google.com...
> "Jim Kennedy" <kennedy-down_with_spammers_at_attbi.com> wrote in message
news:<Yuxpa.611841$S_4.662229_at_rwcrnsc53>...
> > You would be better off creating a package to hold your trigger logic
and
> > creating 1 trigger. Why? Triggers are evaluated each time they are run
vs
> > packages which are compiled once. To multiple triggers means multiple
> > evaluations everytime it runs. Also with all the code in one place it
is
> > much easier to maintain.
> > Jim
>
>
> To add to Jim's post, I would loose the Triggers alltogather and go
> with Packaged Procedure... Kinda hard to do it now since you are
> already in Production... should have thought about this at design time
> -:). One biggest caveat with triggers.... if it is disabled for some
> reason... you are hosed, because triggers don't complain when they are
> disabled.
>
> Just my 2 shiny cents.
>
> Regards
> /Rauf Sarwar

Rauf, so basically, you're saying that instead of using a "before insert" Trigger, I would just call a stored procedure directly, after the insert was complete? (Correct me if I misunderstood that.) The only problem I see with that is the inability to perform validation; if there was something wrong with the row I inserted, I'd then have to delete that row. Is there a workaround for this with a procedure package? Hm; I guess I could've called a procedure, let the procedure validate the information, and if all is well, -then- the procedure would perform the insert to the table?

Triggers are part of a user's schema, correct? If so, then I don't think disabling the triggers is possible; only the system uses the schema account.

Thanks,

-Thomas Received on Thu Apr 24 2003 - 11:42:01 CDT