Exemples

Example 1. Créez un trigger sur un événement de connexion à une base de données pour enregistrer l’événement.

CREATE TRIGGER tr_log_connect
INACTIVE ON CONNECT POSITION 0
AS
BEGIN
  INSERT INTO LOG_CONNECT (ID,
                           USERNAME,
                           ATIME)
  VALUES (NEXT VALUE FOR SEQ_LOG_CONNECT,
          CURRENT_USER,
          CURRENT_TIMESTAMP);
END

Example 2. Créer un déclencheur pour un événement de connexion à une base de données afin de contrôler l’accès.

CREATE EXCEPTION E_INCORRECT_WORKTIME 'La journée de travail n''a pas encore commencé';

CREATE TRIGGER TR_LIMIT_WORKTIME ACTIVE
ON CONNECT POSITION 1
AS
BEGIN
  IF ((CURRENT_USER <> 'SYSDBA') AND
      NOT (CURRENT_TIME BETWEEN time '9:00' AND time '17:00')) THEN
     EXCEPTION E_INCORRECT_WORKTIME;
END

Voir aussi :

ALTER TRIGGER, DROP TRIGGER.

Déclencheurs pour les événements de changement de métadonnées

Les déclencheurs d’événements de changement de métadonnées (déclencheurs DDL) sont conçus pour fournir des restrictions qui seront appliquées aux utilisateurs qui tentent de créer, modifier ou supprimer un objet DDL.Leur autre objectif est de fournir un journal des changements de métadonnées.

Les déclencheurs pour les événements de changement de métadonnées sont une sous-espèce des déclencheurs d’événements de base de données.

Caractéristiques :

Les déclencheurs BEFORE sont exécutés avant les modifications des tables du système. Les déclencheurs AFTER sont exécutés après les modifications apportées aux tables du système.
Lorsqu’une instruction DDL déclenche un déclencheur dans lequel une exception est levée (BEFORE ou AFTER, intentionnellement ou non), l’instruction ne sera pas corrigée. En d’autres termes, les exceptions peuvent être utilisées pour s’assurer que l’instruction DDL est remplacée si certaines conditions ne sont pas remplies.
Les actions de déclenchement DDL ne sont exécutées que lorsque la transaction dans laquelle l’instruction DDL concernée est exécutée est validée. N’oubliez jamais que dans un trigger AFTER, seul ce qui peut être fait après une commande DDL, sans commiter automatiquement les transactions, est possible. Vous ne pouvez pas, par exemple, créer une table dans le déclencheur et l’utiliser là.
Pour les instructions CREATE OR ALTER …, le déclencheur est déclenché une fois pour un événement CREATE ou ALTER, selon que l’objet existait ou non auparavant. Pour les opérateurs RECREATE, le trigger est déclenché pour l’événement DROP si l’objet existait et ensuite pour l’événement CREATE.
Si l’objet de métadonnées n’existe pas, les déclencheurs des événements ALTER et DROP ne sont normalement pas déclenchés. Les exceptions sont décrites dans la clause 6.
L’exception à la règle 5 sont les déclencheurs BEFORE {ALTER | DROP} USER, qui seront appelés même si le nom d’utilisateur n’existe pas. Cela est dû au fait que ces commandes sont exécutées pour une base de données de sécurité pour laquelle aucune vérification de l’existence de l’utilisateur n’est effectuée avant leur exécution. Ce comportement est susceptible d’être différent pour les utilisateurs embarqués, donc n’écrivez pas de code qui en dépende.
Si une exception est levée après le début de l’exécution de la commande DDL et avant l’exécution du déclencheur AFTER, celui-ci n’est pas exécuté.
Les déclencheurs individuels {CREATE | ALTER | DROP} ne sont pas lancés pour les procédures et les fonctions au sein des packages. {PROCÉDURE | FONCTION}.
L’instruction ALTER DOMAIN old name TO new name définit les variables contextuelles OLD_OBJECT_NAME et NEW_OBJECT_NAME dans les déclencheurs BEFORE et AFTER. La variable contextuelle OBJECT_NAME contiendra l’ancien nom de l’objet de métadonnées dans le déclencheur BEFORE et le nouveau nom dans le déclencheur AFTER.

Si ANY DDL STATEMENT est spécifié comme événement, le déclencheur sera invoqué lorsque l’un des événements DDL se produira.