From: "Jason Chapman" <jason@...>
To: <IB-Architect@egroups.com>
Sent: Monday, April 17, 2000 11:57 AM
Subject: Re: [IB-Architect] How about triggers on SELECTS or any DML plus
others.

> Bill,
>
> > You can't insert into a stored procedure, but you can insert into the
> > base table. You can code your applications to insert into the base
> > table but always select from a select procedure that does the logging
> > you want.
> >
> > People can't select from the base table unless you grant them the SQL
> > privilege to do so. Grant SELECT privilege on the base table only to the
> > stored procedure itself.
> This is too restrictive. A selection form may have 15 fields you can enter
> into and the underlying code will produce statements on the fly, almost

all

> of my selection forms work this way.

Isn't there a Pre-post event that allows you to intervene and rewrite the
SQL before it is passed to the server? Then you only need to substitute
ProcedureName with UnderlyingTableName in whatever Insert or Update or
Delete statement the client is trying to execute.

Still, I'm not sure BDE will permit you to treat a stored proc as a live
dataset. I guess automatic code generators always know best. ;-)

> > I think triggers on non-DML events would be useful.
> Excellent - the only issue is that this would meant that the IB engine

would

> have to spontaneously generate a transaction, something it doesn't

currently

> do to my knowledge.

You are correct. It would require a system-generated transaction.

In current InterBase versions, every time you log in, I assume the ibserver
connects to isc4.gdb and has to start a transaction to verify your
user/password.

This sort of goes against my dogmatic statement earlier today that
transactions should always be under user control. Maybe there are
exceptions (e.g. system-initiated actions).

Bill Karwin