Au lieu du temps de l'insertion de l'enregistrement, un déclencheur DML peut agir lorsqu'un enregistrement a été mis à jour sur une table. Pour prendre en charge cette opération, vous pouvez utiliser la formule suivante : CREATE TRIGGER TriggerName
ON TableName
AFTER/FOR UPDATE
AS
TriggerCode
Le nouveau mot-clé dans cette formule est UPDATE. Ceci indique que le déclencheur DML agira lorsque l'enregistrement a été mis à jour.Tout le reste est comme décrit pour l'opérateur INSERT. N'oubliez pas d'utiliser AFTER UPDATE ou FOR UPDATE.
Lorsqu'un enregistrement a été supprimé d'une table, vous pouvez appliquer un déclencheur DML en réponse. Pour la rendre possible, vous pouvez utiliser la formule suivante : CREATE TRIGGER TriggerName ON TableName AFTER/FOR DELETE AS TriggerCode Cette fois, la formule utilise l'opérateur DELETE dans AFTER DELETE ou une expression DELETE. C'est utilisé pour enregistrer la suppression. Les autres facteurs suivent la même description que nous avons vue pour l'opérateur INSERT. Lorsqu'un déclencheur DELETE a statué sur une table, le moteur de base de données crée une table temporaire spéciale nommée deleted. Cette table contient une copie des dossiers qui ont été supprimés. Finalement, si nécessaire, vous pouvez accéder à ce tableau pour en savoir plus sur ces dossiers.
Bien que jusqu'à présent, nous avons créé un seul trigger pour une table, vous pouvez aller plus loin que cela :
Les Déclencheurs DML présentent de nombreuses autres caractéristiques.
Dans la leçon 11, nous avons vu que, pour aider un utilisateur avec l'entrée de données, vous pouvez spécifier qu'une colonne pourrait autoriser ou pas autoriser les null values. Si une colonne est marquée comme étant NOT NULL, lors de la saisie de données, si l'utilisateur ne fait pas ou s'il ne peut pas fournir une valeur pour cette colonne, l'enregistrement ne peut pas être créé. Si vous créez un déclencheur DML qui doit agir contre cette table, si la règle de nullité est enfreinte, le déclencheur ne s'exécutera pas. Dans la leçon 11, nous avons vu que vous pouvez créer une check constraint sur une table pour vous assurer que chaque nouvel enregistrement, ou un enregistrement qui est en cours de modification, suit une certaine règle. Nous savons que si l'enregistrement ne respecte pas cette règle, l'enregistrement ne sera pas créé ou modifié. Si un déclencheur DML est censé agir sur la table, si cette règle n'est pas respectée, le trigger échoue. Une des limites d'une contrainte check est qu'elle ne s'applique qu'à la table à laquelle elle appartient. Il est possible de créer un déclencheur DML pour effectuer une contrainte check sur plusieurs tables. Cela fournit son avantage sur la contrainte check normale. Dans la leçon 16, nous avons étudié la referential integrity et les relations de données. Cela garantit que, lorsqu'un enregistrement est modifié dans une table parent, la modification est apportée également sur la table enfant. Cela signifie également que l'intégrité est appliquée à plusieurs tables. Lorsqu'un déclencheur DML s'exécute, si une règle référentielle est violée, le déclencheur, qui vérifie également l'intégrité référentielle, échoue.
Examinez la table et la vue suivantes dans une base de données : CREATE DATABASE SmallBusiness ;
GO
USE SmallBusiness ;
GO
CREATE TABLE Customers
(
Customer ID int identity (1, 1) primary key not null,
AccountNumber nchar(10),
FullName nvarchar (50)
);
GO
CREATE TABLE DatabaseOperations (
EmployeeName nvarchar(50),
ActionPerformed nvarchar (50),
TimePerformed datetime2
);
GO
De ce que nous avons vu jusqu'à présent, lorsqu'un utilisateur ouvre une table ou une vue pour effectuer la saisie de données, lorsqu'un nouvel enregistrement a été créé, la table ou la vue déclenche un événement. Nous avons vu que, à l'aide d'un déclencheur DML, vous pouvez faire une notification. Par exemple vous pouvez remplir un journal pour conserver une trace des modifications. Par défaut, lorsqu'un enregistrement est soumis, il est enregistré. Dans certains cas, lorsqu'un utilisateur a ouvert une table et essayé d'apporter une modification, tels que l'ajout d'un nouvel enregistrement, la modification d'un enregistrement existant ou une suppression, au lieu d'accepter la modification, vous pouvez la rejeter. Vous pouvez ensuite utiliser un déclencheur DML pour faire une remarque. C'est la base d'une autre catégorie de déclencheurs DML : un déclencheur "instead of". Même si un déclencheur AFTER / FOR agit sur une table après que l'action ait eu lieu, vous souhaiterez peut-être faire quelque chose avant l'événement. Par exemple, vous pouvez empêcher l'utilisateur d'ajouter un nouvel enregistrement sur un conte, ou de modifier un existant ou de le supprimer d'un enregistrement. Bien entendu, il est préférable de s'occuper de cela avant que l'action soit exécutée. Une façon dont vous pouvez effectuer cette opération c'est en créant un déclencheur "instead of".
Même si un déclencheur AFTER peut être appliqué à une table uniquement, un déclencheur "instead of" peut être associé à une table ou une vue. Par conséquent, pour créer un déclencheur "instead of", vous utilisez la formule suivante : CREATE TRIGGER TriggerName
ON TableOrViewName
INSTEAD OF INSERT/UPDATE/DELETE
AS
TriggerCode
Vous commencez avec l'expression CREATE TRIGGER suivie d'un nom pour le déclencheur. Après le nom du trigger, saisissez ON, suivi du nom d'une table ou une vue sur laquelle le déclencheur va agir. Notre examen du déclencheur AFTER, la nouvelle expression ici est INSTEAD OF. Cette expression est suivie par le type d'opération à effectuer. Si vous voulez :
Pour démarrer le code déclenchement, tapez AS et écrivez le code de votre choix. Si vous utilisez l'expression INSTEAD OF, le déclencheur démarre lorsque la table ou la vue est ouverte mais avant qu'un changement ait eu lieu. La différence avec le déclencheur AFTER est que, cette fois, vous pouvez effectuer certaines actions avant que la modification soit effectuée sur la table ou la vue. Cela implique aussi que, si le code du trigger est de créer un nouvel enregistrement, en ce moment, l'enregistrement n'existe pas encore, ce qui signifie que vous ne pouvez pas intercepter cet enregistrement. En ce moment même, vous pouvez empêcher l'enregistrement en cours de création (puisqu'il n'a pas encore été créé quand même). Par exemple, le code suivant n'acceptera pas qu'un nouvel enregistrement soit ajouté à la table : USE SmallBusiness ;
GO
CREATE TRIGGER CreateCustomer
ON Customers
INSTEAD OF INSERT
AS
BEGIN
INSERT INTO DatabaseOperations
GO,
VALUES (SUSER_SNAME(),
N'Attempt to create new record», GETDATE())
END
GO
Si vous souhaitez obtenir une copie de l'enregistrement qui a été affecté par l'événement, vous pouvez y accéder depuis inserted (pour un déclencheur INSERT ou UPDATE) ou depuis le déclencheur deleted (pour DELETE). Voici un exemple : USE SmallBusiness ;
GO
DROP TRIGGER CreateCustomer ;
GO
CREATE TRIGGER CreateCustomer
ON Customers
INSTEAD OF INSERT
AS
BEGIN
INSERT INTO Customers
SELECT AccountNumber, FullName FROM insered
END
GO
AFTER / FOR et un déclencheur INSTEAD OF ont beaucoup de différences. Par exemple :
Dans la leçon 3, nous avons vu que la création d'une base de données utilise une commande DDL (Data Definition Language). Dans la leçon 9, nous avons vu un autre exemple d'une commande DDL qui implique la création d'une table. Chacune de ces opérations de création déclenche un événement. Un déclencheur DDL est un déclencheur qui agit lorsqu'un certain type d'événement DDL se déclenche. Celles-ci incluent la création, la modification ou la suppression d'un objet, pas ses enregistrements. Il s'agit de la principale différence avec un déclencheur DML déclenchant lorsqu'un enregistrement est ajouté ou imposé. Un déclencheur DDL vous donne la possibilité de faire certains travaux administratifs en réponse à l'événement. Par exemple, vous pouvez recevoir une notification ou informer quelqu'un d'autre à l'aide d'un courrier électronique généré automatiquement, ou avertir qu'un (et quel) objet a été créé. Ou vous pouvez utiliser un déclencheur DDL pour annuler l'opération.
Vous créez un déclencheur DDL à l'aide d'un code. La formule de base est la suivante : CREATE TRIGGER TriggerName ON DATABASE/ALL SERVER FOR/AFTER WhatEvent AS TriggerCode Vous commencez un déclencheur DDL avec l'expression CREATE TRIGGER suivie d'un nom pour le nouveau déclencheur. Le nom suit les mêmes règles que nous avons appliquées jusqu'aux objets. Après le nom du trigger, tapez le mot-clé ON :
Après avoir spécifié l'objet (le serveur entier ou seulement la base de données courante) sur lequel le déclencheur agira, tapez FOR ou AFTER. Ceci est suivi de l'événement contre lequel agira le déclencheur. Comme nous l'avons déjà mentionné, les événements sont des commandes DLL. Pour spécifier l'événement, utilisez la formule de la commande avec les mots séparés par un trait de soulignement. Par exemple, si vous souhaitez que le déclencheur agisse lorsqu'une commande CREATE TABLE est exécutée, spécifiez l'événement comme CREATE_TABLE. Après avoir spécifié l'événement qui se déclenche, tapez AS suivi du code normal du déclencheur. Voici un exemple qui rend une note et l'ajoute à une table lorsqu'une nouvelle table a été créée : USE SmallBusiness ;
GO
CREATE TRIGGER LogNewTableCreation
ON DATABASE
FOR CREATE_TABLE
AS
BEGIN
INSERT INTO DatabaseOperations
VALUES(SUSER_SNAME(),
N'A new table was created',
GETDATE())
END
GO
Chaque fois qu'une nouvelle table est créée dans la base de données courante, les longueurs de déclencheur obtiennent le nom de l'utilisateur qui a créé la table, la date et l'heure de la table ont été créées et un message de petite taille. Ces éléments d'information sont ensuite stockés dans une table de journal. Comme mentionné pour les déclencheurs DML, vous gérez les déclencheurs DDL en modifiant ou en les supprimant. Ceux-ci sont effectués en utilisant la même description que nous avons vue pour les déclencheurs DML. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
||
| Précédent | Copyright © 2010 Yevol.com | Suivant |
|
|
||