> Triggers fired in database events are useful for many things:
> On connect/disconnect for logging or logon control.
> On begin transaction for implementation of a "writable transaction
> id" (incrementing a generator and storing in a context variable).
> On commit triggers for business rules validations.
>
> Proposed syntax:
> CREATE TRIGGER <name> <type> AS ...
>
> Types:
> AFTER CONNECT (or LOGON as in Oracle?)
> BEFORE DISCONNECT (or LOGOFF)
> AFTER BEGIN TRANSACTION
> BEFORE COMMIT
>
> They will be stored in RDB$TRIGGERS with RDB$RELATION_NAME = NULL.
>
> RDB$TRIGGER_TYPE will store incompatible values with the current ones,
> but RDB$RELATION_NAME = NULL make they work in different ways.
> Or another field (RDB$TRIGGER_KIND?) could be created to store in what
> event the trigger are fired (DML, DATABASE, DDL in the future), so the
> real trigger type become (RDB$TRIGGER_KIND, RDB$TRIGGER_TYPE).
>
> These triggers may make the database unusable (for example, an exception
> in a CONNECT trigger), so it could be disabled (only for the attachment)
> through a DPB, but only by sysdba/db-owner.
>
> Attachments from GBAK/GFIX/GSEC automatically make this flag ON.
>
> To run CONNECT/DISCONNECT, the engine will start and finish a snapshot
> transaction.
>
> Exceptions in CONNECT, BEGIN TRANSACTION and COMMIT cancels the
> operation. But not cancels (the detach) in DISCONNECT.
>
> Comments?

Sure. Why not create a table RDB$DATABASE_TRIGGERS instead of getting
"incompatible values" in RDB$TRIGGER_TYPE.

What about metadata events? eg: ON CREATE [OF TABLE|VIEW|etc...[OR [...]],
ON ALTER [OF ... ]... ON DROP?

What about ON ROLLBACK?

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com