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

(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 - 08:53:47 CDT