Phil Shrimpton wrote:

>
> If I could...
>
> FOR
> SELECT RDB$FIELD_NAME
> FROM RDB$RELATION_FIELDS
> WHERE RDB$RELATION_NAME = 'MyTable'
> INTO :FIELDNAME
> DO
> BEGIN
> IF (OLD.:FIELDNAME <> NEW.:FIELDNAME) THEN
> EXECUTE PROCEDURE SomeProcedure;
> END
>
> ....I would be a very happy man.
>

Yes, I often think that ability would make me happy, too. But I don't think this
example is a good one. Ideally, this sort of auditing should be built
into/extended from the existing engine. When a record is changed InterBase
already knows what the differences are, and writes the old ones out as back
record versions.

It has to be more efficient to add the ability add an option to write this out
to disc/external file/whatever at that point than to create triggers on every
table that simply repeat something the engine already knows.

I guess the questions that need to be answered are:

o How important is an audit trail option?
o Does dynamic SQL in SPs/Triggers have more utility
than just supporting auditing?

It is not that the two are mutually opposing - maybe both are needed. But if the
aim is to implement an audit trail, is the DSQL option the right solution or
just a symptom that the engine doesn't surface auditing yet?

Paul
--

Paul Reeves
Fleet River Software