Subject Re: [IB-Architect] Compile Time Triggers
Author Dalton Calford
It would require more work on the developers side, and would require that the
developer understands the implications and traps of the method involved.
But, it would allow the fuctionality to be implemented immediately, as well
as making other functionality possible.

I mentioned to Ann awhile back about the usefullness (and drawbacks) of
various new triggers (on database connect, on database disconnect, on select,
on row_select, etc) that would (combined with more procedure language power)
make IB extreamly versitile, but, historic circumstances and other
commitments surely disrailed that old conversation.

We had gotten as far as what possible transaction the trigger would be in and
what other ramifications may plague us. I will try to find my old notes on
the subject.

I personally love the idea of a select trigger, but I would want it as a
trigger/proc language implementation vs a external plugin. I have alway put
the idea away on a shelf with the idea of dynamic sql within proc/trigger

best regards


On Friday 04 May 2001 14:57, you wrote:
> At 02:42 PM 5/4/01 -0400, you wrote:
> >How bout a view that can select from a stored procedure.
> >This would allow you to put whatever logic you wish into the stored
> procedure.
> >With the view triggers you can make the view updateable.
> >With extra global variables you can manipulate the view however you wish
> >(base it on time of day, role, user name, ip address etc)
> >
> >>From what I understand, this would be the easiest and most flexible
> approach.
> >You give each client access to the view, not the table.
> A join of a stored procedure can't be optimized. A view doesn't
> have the computational power. Having the retrieval semantics in
> the stored procedure and the update semantics in view triggers
> doesn't strike me as particularly elegant, but not a show
> stopper.
> Jim Starkey
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to