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
--
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family. Remove the negative part, keep the minus sign. You can figure
it out.
"Thomas T" <T_at_T> wrote in message news:3ea69d62$1_at_rutgers.edu...
> (laughs) Well if I had gone with the "secondary" trigger plan, if there
> were any other problems, I would've just went into the DLL. This isn't
> really one of data accuracy (a blank space is decoded properly in other
> queries), it's more of eliminating extra "future" sql text. But,
yesterday
> afternoon, I decided to alter the DLL code anyway; I'm about to begin
> testing.
>
> The DLL has nothing to do directly with the trigger code, my DLL is what
> actually performs the insert to the database.
>
> You said multiple triggers would affect performance- how badly? Or is
this
> just in theory? Is there any link on the 'net that deals with this in a
> real-world situation?
>
> Thanks!
>
> -Thomas
>
>
> "Anurag Varma" <avdbi_at_hotmail.com> wrote in message
> news:aVopa.8878$uZ4.5357_at_news02.roc.ny.frontiernet.net...
> > I did not really understand what the DLL really had to do with your
> trigger code?
> >
> > afaik: Multiple similar type triggers should be avoided firstly for
> maintenance reasons
> > and secondly for performance.
> > With excuses like you have given, pretty much in the future, that table
> will end up having umpteen triggers!
> >
> > Anurag
> >
> >
> > "Thomas T" <T_at_T> wrote in message news:3ea56f28$1_at_rutgers.edu...
> > > First, the platform information: Server is Win2k, database is Oracle
8i
> > > (8.1.7). (Shouldn't we all begin our questions like this?) :)
> > >
> > > I'm wondering about the real-world (non theoretical!) impact of
multiple
> > > "before" triggers on a table. All I can find on the 'net is that
> multiple
> > > before/after update/insert triggers aren't a good idea, since you
can't
> > > specify what order they execute in. But what if order doesn't matter?
> > >
> > > I have a "before insert" trigger on a table that brings in the next
> sequence
> > > value, and saves it to a field in the table, as a "confirmation
number".
> > > I'd like to add a second "before insert" trigger that checks to see if
a
> > > value consists of a single blank character; the space (ASCII character
> #32).
> > > If the space exists, I'd like to set the column to null. The order of
> these
> > > triggers doesn't really matter, as long as they fire. I already have
an
> > > "after" trigger, which manipulates another table (upon a successful
> insert),
> > > so I can't change that after trigger at all.
> > >
> > > Is this a good idea or not? I'd rather not alter the original
"before"
> > > trigger, since it's in production already. I can alter my query, but
> the
> > > original problem still exists- I'd have to alter "future" queries,
too.
> To
> > > change the actual SQL insert of the values, I'd have to dive back into
> my
> > > DLL code (Visual C++ 6.0, OLE DB, ATL, COM)- and then this change
could
> > > affect the whole DLL! But, if creating multiple "before" triggers is
> very
> > > bad in terms of design and performance and accuracy, I might have to
go
> into
> > > the DLL.
> > >
> > > Thanks for any/all ideas/opinions!!
> > >
> > > -Thomas
> > >
> > >
> >
> >
>
>
Received on Wed Apr 23 2003 - 09:33:28 CDT
