Petit guide de Transact SQL (v2000)Date de publication : 16/04/2004
Par
SQLPro (autres articles) (CV) niveau : intermédiaire Transact SQL, est une extension du dialecte SQL de SQL Server et constitue un langage procédural pour coder les procédures stockées et les triggers du SGBDR de Microsoft. 1. Positionnement du langage 1.1. Historique 1.2. Utilisation 1.3. Conclusion 2. Syntaxe 2.1. Identifiant 2.2. Variables 2.3. Structures basiques 2.4. Variable de retour 2.5. Variables "système" 2.6. Flags 2.7. Batch et GO 2.8. Quelques fonctions de base 2.9. Commentaires 3. UDF : fonction utilisateur 3.1. Fonction renvoyant une valeur 3.2. Fonction renvoyant une table 4. Procédures stockées 4.1. Entête de procédure 4.2. Paramètres, variables de retour et ensemble de données 4.3. Gestion des erreurs 4.4. Procédures stockées prédéfinies 4.5. Verrouillage 4.6. Gestion de transactions 4.7. Les curseurs 5. Les triggers 5.1. Mise en place d'un trigger 5.2. Syntaxe d'un trigger MS SQL Server 2000 5.3. Eléments du langage spécifique aux triggers 5.3.1. Pseudo tables INSERTED et DELETED 5.3.2. Fonctions UPDATE et COLUMNS_UPDATED 5.3.3. Annulation des effets d'un trigger 5.4. Exemples de triggers 6. Cryptage du code, liaison au schema et recompilation 7. ANNEXE BIBLIOGRAPHIQUE 1. Positionnement du langageTransact SQL est un langage procédural (par opposition à SQL qui est un langage déclaratif) qui permet de programmer des algorithmes de traitement des données au sein des SGBDR Sybase Adaptive Server et Microsoft SQL Server. 1.1. HistoriqueIl a été créé par Sybase INC. à la fin des années 80 pour répondre aux besoins d'extension de la programmation des bases de données pour son SGBDR. Ce langage est donc commun aux deux produits (MS SQL Server et Sybase Adaptive) avec des différences mineures dans les implémentations. Il sert à programmer des procédures stockées et des triggeurs (déclencheurs). Transact SQL n'a aucun aspect normatif contrairement à SQL. C'est bien un "produit" au sein commercial du terme. En revanche depuis SQL 2 et plus fortement maintenant, avec SQL 3, la norme SQL a prévu les éléments de langage procédural normatif propre au langage SQL. Mais il y a une très grande différence entre la norme du SQL procédural et Transact SQL. D'autres SGBDR utilisent d'autres langages procéduraux pour l'implémentation de procédures stockées et de triggers. C'est le cas par exemple du PL/SQL (Programming Langage) d'Oracle. Il existe encore peu de SGBDR dont le langage procédural est calé sur la norme. Mais on peut citer OCELOT (SQL 3), PostGreSQL (SQL 2). Par rapport à la concurrence voici une notation approximative (sur 5) des différents langage procéduraux :
Il s'agit bien entendu d'une notation toute personnelle parfaitement sujette à caution ! 1.2. UtilisationTransact SQL doit être utilisé :
En revanche il faut tenter de ne pas l'utiliser pour le calculs de règles métier, l'idéal étant de déporter cela dans des objets métiers. Enfin l'usage de trigger pour de la réplication est à proscrire. 1.3. ConclusionNous retiendrons que ce qui compte dans l'étude de ce langage, c'est plus de comprendre ses grands concepts et son esprit afin de pouvoir le transposer sur d'autres SGBDR plutôt que d'apprendre par cur telle ou telle instruction, d'autant que la documentation sur ce langage est assez fournie. ATTENTION : nous étudirons ici la version Microsoft du langage Transact SQL 2. Syntaxe2.1. IdentifiantVoici les règles de codage des identifiants (nom des objets) Les identifiants SQL :
Le symbole @ commence le nom de toute variable. Le symbole dédoublé @@ commence le nom des variables globales du SGBDR. Le symbole # commence le nom de toute table temporaire (utilisateur) Exemple :
Le symbole dédoublé ## commence le nom de toute table temporaire globale. Conséquence : la libération des tables temporaires est consécutif à la libération des utilisteurs. Nota : SQL Server utilise un base particulière "tempDB" pour stocker la définition des objets temporaires. Attention : pour des raisons de performances il est fortement déconseillé d'utiliser le SELECT
INTO
qui n'est d'ailleurs pas normalisé. Un identifiant est dit "qualifié" s'il fait l'objet d'une notation pointée définissant le serveur, la base cible et l'utilisateur : serveur.base_cible.utilisateur.objet Exemple :
Attention : ceci suppose que les serveurs soient connus les uns des autres (procédure de "linkage") On peut ignorer le serveur, comme l'utilisateur, dans ce cas c'est l'utilisateur courant qui est pris en compte : base_cible..objet et au sein de la base : objet Un identifiant ne doit pas être un mot clef de SQL, ni un mot clef de SQL Server ni même un mot réservé. Dans le cas contraire il faut utiliser les guillemets comme délimiteur. La notion de constante n'existe pas dans Transact SQL. 2.2. VariablesLes types disponibles sont ceux de SQL :
Auxquels il faut ajouter le type :
que nous verrons plus en détail. Les valeurs de types chaînes doivent être délimitées par des apostrophes. Une variable est déclarée à tout endroit du code par l'instruction DECLARE : Exemple :
Une variable est assignée par l'instruction SET :
Avant toute assignation, une variable déclarée est marquée à NULL. Remarques :
Exemple :
Attention : dans le cas d'une requête renvoyant plusieurs lignes, seule la valeur de la dernière ligne sera récupéré dans la variable. ASTUCE : si vous désirez concaténer toutes les valeurs d'une colonne dans une seule variable, vous pouvez utiliser la construction suivante :
NOTA : la notion de constante n'existe pas. 2.3. Structures basiquesLa structure :
permet de définir des blocs d'instructions. Les branchements possibles sont les suivants :
Les instructions :
permettent respectivement d'interrompre ou de continuer autoritairement une boucle. Remarques :
Exemple : Il s'agit de donner la liste de tous les nombres premiers entre 1 et 5000. Première version en code procédural :
Par ce code procédural, nous avons utilisé la formulation suivante : "n est premier si aucun nombre de 2 à n-1 ne le divise". Une autre façon de faire est de travailler en logique ensembliste. Si nous disposons d'une table des entiers, il est alors facile de comprendre que les nombres premiers sont tous les nombres, moins ceux qui ne sont pas premiers... Il s'agit ni plus ni moins que de réaliser une différence ensembliste.
Notez la différence de vistesse d'exécution entre les deux manières de faire... Enfin, on peut encore optimiser l'une et l'autre des procédure en limitant le diviseur au maximum à CAST(SQRT(CAST(n2.n AS FLOAT)) AS INTEGER) + 1, car le plus grand des diviseurs d'un nombre ne peut dépasser sa racine carrée. 2.4. Variable de retourToute procédure stockée renvoie une variable de type entier pour signaler son état. Si cette variable vaut 0, la procédure s'est déroulée sans anomalie. Tout autre valeur indique un problème. Les valeurs de 0 à -99 sont réservées et celles de 0 à -14 sont prédéfinies. Par exemple la valeur -5 signifie erreur de syntaxe. On peut assigner une valeur de retour de procédure à l'aide de l'instruction RETURN :
2.5. Variables "système"SQL Server défini un grand nombre de "variables système" c'est à dire des variables définies par le moteur. En voici quelques unes :
2.6. FlagsPour manipuler les effets de certaines variables, comme pour paramétrer la base de données, il est nécessaire de recourir à des "flags". SET NOCOUNT ON / OFF empêche/oblige l'envoi au client de messages pour chaque instruction d'une procédure stockée affichant la ligne « nn rows affected » à la fin d'une instruction (SELECT, INSERT, UPDATE, DELETE). Remarque : il est recommandé de désactiver le comptage dans les procédures stockées afin d'éviter l'envoi intempestif de lignes non lues qui génère du trafic réseau et rallonge les temps d'exécution. SET ANSI_DEFAULTS ON / OFF Conformation d'une partie de SQL Server à la norme SQL 2 SET DATEFORMAT {format de date} Fixation du format de date par défaut SET IDENTITY_INSERT nomTable ON / OFF Active, désactive l'insertion automatique de colonne auto incrémentées (identity) dans la table spécifiée. Exemple : insertion de lignes dont la clef est spécifiée dans une table données pourvue d'un auto incrément :
2.7. Batch et GOUn batch est un ensemble d'ordres SQL ou Transact SQL passé en un lot. Il peut être exécuté en lançant un fichier vers le moteur SQL ou encore en l'exécutant dans l'analyseur de requêtes. la plupart du temps un batch est utilisé pour créer les objets d'une base et lancer au coup par coup certaines procédures lourdes (administration notamment). Le mot clef GO permet de forcer l'exécution de différents ordres SQL d'un traitement par lot. Hors d'un contexte de transaction, le serveur peut choisir dans les différents ordres qui luis ont proposés simultanément d'exécuter telle ou telle demande dans l'ordre que bon lui semble. La présence du mot clef GO dans un fichier d'ordre SQL passé au serveur permet de lui demander l'exécution immédiate de cet ordre ou de l'ensemble d'ordres. Dans ce, cas l'instruction GO doit être spécifié pour chaque ordre atomique ou bien pour chaque ensemble cohérents. En fait le mot clef GO agit comme si chaque ordre était lancé à travers un fichier différent. Enfin, un batch est exécuté en tout ou rien. Ainsi, en cas d'erreur de syntaxe par exemple, même sur le dernier ordre du lot, aucun des ordres n'est exécuté. Attention :
2.8. Quelques fonctions de baseUSE est une instruction permettant de préciser le nom de la base de données cible. En effet il arrive que l'on soit obligé de travailler depuis une base pour en traiter une autre. C'est le cas notamment lorsque l'on veut créer une base de données et y travailler sur le champ. La seule base en standard dans MS SQL Server est la base "master" qui sert de matrice à toutes les bases créées. Elle contient les procédures inhérentes au serveur mais aussi celles inhérentes aux bases nouvellement créées, ainsi que les méta données spécifiques de la nouvelle base (tables dont le nom commence par "syS..."). Exemple : création d'une base de données depuis la base MASTER et création d'une table dans cette nouvelle base :
PRINT est une instruction permettant de générer une ligne en sortie de procédure. Elle doit être réservée plus à la mise au point des procédures stockées que pour une utilisation en exploitation. EXEC est une instruction permettant de lancer une requête ou une procédure stockée au sein d'une procédure ou un trigger. La plupart du temps il n'est pas nécessaire d'utilise l'instruction EXEC, si l'intégralité de la commande SQL ou de la procédure à lancer est connu. Mais lorsqu'il s'agit par exemple d'un ordre SQL contenant de nombreux paramètres, alors il est nécessaire de le définir dynamiquement. Exemple : voici une procédure cherchant dans toutes les colonnes d'une table l'occurrence d'un mot :
2.9. CommentairesComme dans le cadre du langage SQL de base, pour placer des commentaries il suffit d'utiliser les marqueurs suivants :
3. UDF : fonction utilisateurUne UDF, autrement dit User Define Function ou Function Définie par l'Utilisateur est une fonction que le concepteur de la base écrit pour des besoins de traitement au sein des requêtes et du code des procdures stockées ou des triggers. Elle fait donc partie intégrante de la base ou elle est considérée comme un objet de la base au même titre qu'une table, une vue, un utilisateur ou une procédure stockée. Il existe deux grands types de fonctions : celles renvoyant une valeur et celles renviyant un jeu de données (table). 3.1. Fonction renvoyant une valeurLa syntaxe est assez simple :
Exemple, calcul de la date de pâque pour une année donnée :
On utilise une telle fonction au sein d'une requête, comme une fonction SQL de base, à ceci près que, pour une raion obscure, il faut la faire précéder du nom du propriétaire. Exemple :
3.2. Fonction renvoyant une tableIl existe deux manières de procéder : soit par requête directe (table en ligne), soit par construction et alimentation d'une table (table multi instruction). La première syntaxe (table est ligne) est très simple. Voici un exemple, qui construit et renvoi une table des jours de semaine :
La seconde syntaxe demande un peu plus de travail, car elle se base sur une variable "table". En voici la syntaxe :
Voici un exemple, qui construit une table d'entier limité à MaxInt et comprenant ou non le zéro (entiers naturels) :
NOTA : SQL Server interdit l'utilisation de fonctions non déterministe au sein des fonctions utilisateur. Par exemple, la fonction CURRENT_TIMESTAMP qui renvoie la date/heure courante ne peut être utilisée dans le cadre de l'écriture d'une UDF. Il y a cependant moyen de contourner ce problème en utilisant par exemple une vue...
4. Procédures stockéesLe but d'une procédure stockée est triple :
Dans ce dernier cas la méthode traditionnelle nécessitait de nombreux aller et retour entre le client et le serveur et congestionnait le réseau. Une procédure stockée est accessible par l'interface de l'Entreprise Manager. Elle peut aussi être créée par l'analyseur de requête. ![]() En créant une nouvelle procédure stockée on se trouve devant une fenêtre de définition de code : ![]() ATTENTION : Les procédures stockées (v7) sont limitées à :
4.1. Entête de procédureElle commence toujours pas les mots clef CREATE PROCEDURE suivi du nom que l'on veut donner à la procédure stockée. Les paramètres et leur type, s'il y en as suivent le nom. L'entête se termine par le mot clef AS. Exemple :
4.2. Paramètres, variables de retour et ensemble de donnéesUne procédure stockée peut accepter de 0 à 1024 paramètres (arguments). Elle a toujours une valeur de retour qui par défaut est le code d'exécution (entier valant 0 en cas de succès). Elle peut retourner des lignes de table comme une requête. Pour déclarer les paramètres il faut les lister avec un nom de variable et un type. Par défaut les paramètres sont des paramètres d'entrée. Comme pour toutes les listes le séparateur est la virgule. On peut déclarer des valeurs par défaut et spécifier si le paramètre est en sortie avec le mot clef OUTPUT. Exemple :
Pour récupérer la valeur de d'un paramètre OUTPUT il faut préciser une variable de récupération de nature OUTPUT dans le lacement de l'exécution. Exemple :
Un paramètre de type CURSOR (curseur) est un cas particulier et ne peut être utilisé qu'en sortie et conjointement au mot clef VARYING qui spécifie que sa définition précise n'est pas connue au moment de la compilation (le nombre et le type des colonnes n'est pas défini à cet instant).
Un tel paramètre peut être réutilisé dans une autre procédure stocké ou dans un trigger. Comme nous l'avons vu, toute procédure stockée renvoie une variable de type entier pour signaler son état. Si cette variable vaut 0, la procédure s'est déroulée sans anomalie. Tout autre valeur indique un problème. Les valeurs de 0 à -99 sont réservées et celles de 0 à -14 sont prédéfinies. Par exemple la valeur -5 signifie erreur de syntaxe. Bien entendu on peut assigner une valeur de retour de procédure à l'aide de l'instruction RETURN. Une procédure stockée peut en outre renvoyer un jeu de résultat sous la forme d'un ensemble de données à la manière des résultats de requête. Exemple :
4.3. Gestion des erreursIl existe différents niveaux d'erreurs et différents moyens de les gérer. Considérons une procédure stockée qui aurait pour effet de supprimer une ligne d'une table en s'assurant de supprimer préalablement toutes les lignes de tous les descendants concernés. L'entête d'une telle procédure pourrait s'écrire :
Si la ligne considérée n'est pas retrouvée dans la table des clients, comme si la valeur du paramètre est NULL, cette procédure échouera sans indiquer d'anomalie. Il faut donc procéder à des tests préalables (nullité, existence
). Sans cela on dit que l'on à une "exception silencieuse". Pour les exceptions plus flagrantes, SQL Server fournit la variable globale @@error que l'on peut tester à tout instant. Cette variable est mise à jour à chaque instruction. Le code continue de s'exécuter même après une erreur. Pour gérer les erreurs, SQL Server dispose de la levée des erreurs à l'aide de l'instruction RAISERROR et l'utilisation du GOTO combiné à une étiquette de branchement pour la reprise sur erreur, permet de centraliser la gestion des erreurs à un seul et même endroit du programme. Voici un exemple mettant en uvre ces principes :
4.4. Procédures stockées prédéfiniesSQL Server possède des procédures stockées pré établies, un peu à la manière d'une bibliothèque d'utilisation. Elles servent essentiellement à l'administration (gestion des utilisateurs et des bases) et à l'information (dictionnaire des données). Elle se situent toutes dans la base "master". Ainsi, la procédure stockée "sp_help" fournit une description de n'importe quel objet de la base. Pour appeler de telles procédures, il n'est pas nécessaire de préciser le nom de la base "master", ce nom est implicite. Ces procédures stockées permettent :
Nota : des procédures stockées dites étendues (dont le nom commence généralement par "xp_") font appel à du code C sous forme de DLL. Exemple : xp_cmdShell, permet de lancer un programme en ligne de commande depuis SQL Server (procédure dont l'utilisation est à déconseiller !) Exemple - création d'un type utilisateur (DOMAINE SQL 2) pour spécification numérique de la valeur d'un mois avec contrôle de validité :
4.5. VerrouillageLe verrouillage est la technique de base pour assurer les concurrences d'accès aux ressources. On peut observer les verrous posés lors des manipulations de données à l'aide de la procédure stockée sp_lock. De même on peut savoir qui utilise quoi à l'aide de la procédure stockée sp_who. SQL Server pose en principe les bons verrous lors des requêtes. Mais il peut arriver que l'on souhaite :
Dans les deux cas il faut compléter les ordre SQL par une description des verrous attendus. Voici les paramètres de verrouillage que l'on peut spécifier :
Ces paramètres se précisent dans un ordre SQL après le nom de la table et le mot clef WITH en utilisant le parenthèsage. Exemples : Accélération d'une extraction de données en demandant la suppression du verrouillage :
Verrouillage exclusif de la table le temps de la mise à jour :
On peut combiner certains paramètres de verrouillage. Exemple :
Attention : la manipulation des verrous est affaire de spécialistes. Une pose de verrous sans étude préalable de la concurrence d'exécution des différentes procédures stockées d'une base, peut conduire à des scénarios de blocage, comme "l'étreinte fatale". 4.6. Gestion de transactionsToute ordre SQL du DML est une transaction (SELECT INSERT, UPDATE, DELETE). Parce que SQL Server fonctionne en "AUTOCOMMIT", une combinaison de différents ordres nécessite la pose explicite d'une transaction. Ceci se fait par l'instruction BEGIN TRANSACTION et doit être terminé soit par un ROLLBACK, soit par un COMMIT. Une transaction peut être anonyme ou nommée. De toute façon SQL Server lui attribue un identifiant interne unique. Exemple simple. Il s'agit de réserver 3 place dans le vol AF714 pour le client 123, s'il y a bien de la place pour ce vol !
SQL Server permet aussi de définir des points de sauvegarde, que l'on peut considérer comme un validation partielle d'une transaction. Pour définir un point de sauvegarde il faut utiliser l'instruction SAVE TRANSACTION avec un nom de préférence (pas obligatoire). Par conséquent pour faire un ROLLBACK partiel il suffit de préciser le nom du point de sauvegarde dans l'ordre ROLLBACK. L'utilisation de la variable @@TranCount permet de savoir le nombre de transaction ouvertes en cours. Une bonne transaction ne saurait être bien gérée sans une appréciation claire du niveau d'isolation. SQL Server gère les 4 niveaux de la norme SQL 2. La commande SET TRANSACTION ISOLATION LEVEL dont les options sont READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ et SERIALIZABLE permet de définir le niveau d'isolation d'une transaction.
Attention : par défaut SQL Server travaille au niveau READ COMMITTED. Ceci explique sa rapidité comparée a des serveurs qui fonctionnent par défaut au niveau d'isolation maximal mais peut s'avérer catastrophique pour l'intégité des données !!! CONSEIL : il est toujours préférable d'utiliser la gestion des transactions que de manipuler les verrous, sauf en ce qui concerne la "lecture sale" notamment dans le cadre d'une utilisation client/serveur en mode déconnecté (par exemple dans le cadre de restitutions documentaires pour un site web). NOTA : SQL Server permet de gérer des transactions distribuées et gère le "commit à deux phases" mais sans permettre l'utilisation de points de sauvegarde. Exemple : gestion d'un arbre modélisé par intervalle Pour une illustration plus complète des procédures stockées nous allons montrer les différentes procédures nécessaires pour faire "fonctionner" un arbre modélisé sous forme intervallaire. Pour une développement plus complet de ce sujet, lire l'article sur la représentation intervallaire des arborescences Dans notre cas nous allons considérer une table permettant de gérer le développement des projet d'une entreprise. Voici la table du développement. Elle contient les informations de chaque noeuds, y compris son identifiant, sojn libellé, ses bornes droite et gauche et son niveau :
Tout d'abord voici la procédure d'insertion d'un fils ainé, c'est à dire d'un fils qui sera le plus proche du sommet au moment de l'insertion. On passe à la procédure l'identifiant du noeud père et le libellé. Une variable de retour permet de conaître l'état de l'insertion.
Pour le fils cadet, la procédure n'est pas plus compliquée :
Voici maintenant comment on insère un frère à droite d'un autre :
Même insertion en frère à gauche :
Enfin, comment supprimer. Notez l'argument "récursif" passé en paramètre de procédure pour spécifier si l'on tue toute la lignée ou si l'on laisse survivre les descendants !
4.7. Les curseursLes curseurs sont des mécanismes de mémoire tampons permettant d'accéder aux données renvoyées par une requête et donc de parcourir les lignes du résultat. Un curseur se définit dans une instruction DECLARE possédant une requête de type SELECT. Il convient de définir pour chaque colonne renvoyé une variable de type approprié. Pour lancer la requête associée (et donc placer les données dans les buffers appropriés) il faut utiliser l'instruction OPEN. Un curseur doit être refermé avec l'instruction CLOSE. Pour libérer la mémoire utilisée par un curseur, il faut utiliser l'instruction DEALLOCATE. Pour lire les données de la ligne courante et les associées aux variables du curseur il faut utiliser l'instruction FETCH. Par défaut l'instruction FETCH navigue en avant d'une ligne à chaque lecture dans l'ensemble des données du résultat. Pour naviguer différemment, on peut qualifier le FETCH avec les mots clef NEXT, PRIOR, FIRST, LAST, ABSOLUTE n et RELATIVE n, mais il faut avoir déclaré le curseur avec l'attribut SCROLL... Enfin la variable @@fetch_Status permet de savoir si la dernière instruction FETCH passée s'est correctement déroulée (valeur 0), ce qui permet de tester si l'on est arrivé en fin de parcours de l'ensemble de données. Une boucle traditionnelle de manipulation d'un curseur prend la forme suivante :
On constate que l'instruction FETCH apparaît deux fois. Une première fois avant la boucle WHILE une seconde fois à l'intérieur et en dernière ligne de la boucle WHILE. C'est la façon la plus classique et la plus portable d'utiliser des curseurs. NOTA : les performances sont en baisse lorsque l'on utilise tout autre déplacement que le NEXT. Remarque : il est possible d'effectuer des mises à jours de données via des curseurs, mais cela n'est pas conseillé. Dans ce cas il faut préciser en fin de déclaration du curseur : FOR UPDATE OF liste_colonne On peut aussi faire du "dirty read" avec les curseurs de SQL Server en précisant l'attribut INSENSITIVE juste après le nom du curseur. La syntaxe complète SQL 2 de la déclaration d'un curseur dans MS SQL Server est :
La syntaxe admise par le Transact SQL de MS SQL Server est plus complète mais moins portable :
Exemple : voici un petit exercice consistant, pour chaque table de la base à en donner le nombre de ligne. Pour cela on utilise une vue d'information de schema pour récupérer le nom de toutes les tables et les traiter.
Exemple : un deuxième exemple plus complexe nous montre comment rechercher l'occurence d'un mot dans toutes les colonnes de toutes les tables de la base. C'est une extension de l'exemple vu au paragaphe 4.3 :
Pour mettre à jour des données dans un curseur, il faut le déclarer avec la clause FOR UPDATE et utiliser un ordre UPDATE portant sur la table visé avec une clause WHERE dans laquelle on référence la ligne courante du curseur. Bien entendu la requête situé dans le curseur ne peut porter que sur une seule table ! Exemple :
5. Les triggersLes triggers ou déclencheurs servent à étendre les mécanismes de gestion de l'intégrité référentielle (liens d'héritage par exemple) et permettre le contrôle de saisie. Il s'agit de code déclenché lors de certains événements de la base de données. Un trigger est toujours rattaché à une table. Les événements qui déclenche un trigger sont :
Ils sont donc déclenchés systématiquement par une requête SQL, après l'exécution de cette requête (AFTER), ou à la place de l'exécution de cette requête (INSTEAD). SQL Server n'implémente pas de trigger BEFORE (avant exécution), mais nous verrons comment le simuler... En fait le trigger correspond à la programmation des événements des langages d'interfaces graphique, comme Delphi ou Visual Basic. 5.1. Mise en place d'un triggerOn peut définir un trigger par l'interface de l'Entreprise Manager comme par un batch créée, par exemple dans l'analyseur de requête. ![]() Et cliquer sur l'icône approprié "Trigger" ![]() 5.2. Syntaxe d'un trigger MS SQL Server 2000
Cette syntaxe ne tient pas compte de toutes les possibilités. Emplois typiques :
5.3. Eléments du langage spécifique aux triggers5.3.1. Pseudo tables INSERTED et DELETEDLes pseudo tables INSERTED et DELETED contiennent les données respectives de l'insertion ou la mise à jour (INSERTED) ou bien de la suppression (DELETED). On peut les utiliser dans des requêtes comme des tables ordinaires. La structure de ces tables est calquée sur le structure de la table sur laquelle repose le trigger. 5.3.2. Fonctions UPDATE et COLUMNS_UPDATEDLa fonction UPDATE permet de tester si une colonne est visé par un changement de valeur. Elle s'emploie de la manière suivante :
Elle ne peut être utilisée que dans les triggers de type INSERT et UPDATE. La fonction COLUMNS_UPDATED() permet d'interroger les colonnes visées par un ordre INSERT ou UPDATE. Elle utilise un masque binaire constitué par le rang ordinal des colonnes de la table. Son emploi syntaxique est le suivant :
Un exemple va nous permettre de préciser le fonctionnement de ce mécanisme. Soit une table de prospects comme suit :
Les valeurs ordinales des colonnes de cette table (en fait la position des colonnes lors de la construction de la table) sont les suivantes : PSP_ID PSP_NOM PSP_PRENOM PSP_SAISIE PSP_TEL ----------- --------------- ------------------ ---------------- -------------------- 1 2 3 4 5 Vous pouvez d'ailleurs retrouver la valeurs de ces positions ordinales par une requête dans les vue de schéma normalisé, comme suit :
Dès lors, si vous voulez savoir si l'ajout ou la mise à jour concerne les colonnes PSP_NOM, PSP_PRENOM et PSP_TEL, il faut écrire :
Le chiffre 22 s'obtenant par l'addition des puissances de 2 de la position ordinale des colonnes visées, c'est à dire : colonne : PSP_ID PSP_NOM PSP_PRENOM PSP_SAISIE PSP_TEL
---------- ---------- ---------- ---------- ----------
ordinal : 1 2 3 4 5
puissance 2 : 2^0 = 1 2^1 = 2 2^2 = 4 2^3 = 8 2^4 = 16
retenu : non oui oui non oui
valeur : 0 2 4 0 16 = 22 (SOMME de 16 + 4 + 2)
5.3.3. Annulation des effets d'un triggerPour empêcher un trigger de produire son effet on peut utiliser le ROLLBACK qui dans ce cas peut porter sur la transaction (ROLLBACK TRANSACTION celle qui a déclenchée le trigger par exemple) ou uniquement le trigger (ROLLBACK TRIGGER) c'est à dire sur les seuls effets de ce dernier. C'est par ce biais que l'on peut simuler un trigger BEFORE : utiliser un trigger AFTER et le "rollbacker" ou bien utiliser un trigger INSTEAD et insérer quand même dans la table de destination. Attention : un trigger n'est déclenché qu'une seule fois, même si l'ordre SQL qui l'a déclenché concerne de nombreuses lignes. 5.4. Exemples de triggersPremier exemple - contrôle de validité de format de données. On désire empêcher la saisie de tout numéro de téléphone dans la table client qui possède d'autres caractères que des chiffres (au maximum 20) et des points de séparation :
La première tentative de modification :
provoque une erreur et l'insertion n'a pas lieu. Tandis que la seconde va bien produire ses effets :
Le seul inconvénient est que cette façon de procéder rejette toutes les lignes insérées ou mise à jour sans accepter celles qui peuvent être correctement formatées. D'autre part on exécute cette procédure jusqu'au bout, même si la colonne CLI_TEL ne subie aucune modification. Néanmoins ce cas peut être résolu par un traitement spécifique utilisant la fonction UPDATE :
Second exemple - L'exercice consiste maintenant à corriger à la volée des saisie incorrectes. Tous les caractères de séparation tel que le tiret ou l'espace d'un numéro de téléphone devra être convertis en point.
Ainsi l'ordre :
donne pour résultat : cli_id cli_nom Cli_tel ----------- -------------------------------- -------------------- 1 DUPONT 88.77.66.55.44 et la saisie du numéro de téléphone a été corrigé à la volée et se trouve désormais au format voulu ! Attention : le danger réside dans l'exécution récursive de tels triggers. Comme l'on remet à jour la table à l'intérieur même du trigger, celui-ci est à nouveau déclenché. Le phénomène, s'il n'était pas limité, pourrait provoquer une famine du processus. Il faut donc veiller à le limiter. Dans ce sens SQL Server propose deux garde fous : le premier, intrinsèque au serveur est de ne jamais dépasser 16 niveaux de récursion. Le second est de proposer une limite plus restrictive à l'aide de la procédure sp_configure, qui permet de modifier la variable nested triggers afin d'étendre les limites d'appel de triggers imbriqués. De plus pour connaître le niveau d'imbrication du trigger à l'intérieur de ce dernier il suffit de lancer la fonction TRIGGER_NESTLEVEL() qui renvoie une variable de niveau. Conseil : il est préférable de ne pas utiliser de triggers imbriqués et donc de laisser le paramètre nested triggers de la configuration à 1. Bien entendu ou pourrait être beaucoup plus fin dans ce genre de contrôle et analyser puis remplacer, caractères par caractères. A titre de troisième exemple, nous allons réaliser un tel trigger :
Quatrième exemple - il s'agit maintenant de supprimer en cascade dans différentes tables. Si un client (table T_CLIENT) est supprimé on doit lui retirer les factures (table T_FACTURE) qui le concerne :
Bien entendu si vous avez placé de nouveau un trigger permettant de faire de la suppression dans les lignes de facture, alors il sera déclenché et supprimera les occurrences désirées. C'est ce que l'on appelle un déclenchement de triggers en cascade. Cinquième exemple - la gestion d'un lien d'héritage suppose souvent une exclusion mutuelle entre les fils nous allons voir comment gérer ce cas de figure. Partons d'une table T_VEHICULE dont la spécialisation provoque deux tables : T_AVION et T_BATEAU. Un véhicule peut être un avion ou bien un bateau mais pas les deux. Une valeur de clef présente dans T_VEHICULE peut donc se retrouver soit dans T_BATEAU soit dans T_AVION mais on doit éviter qu'elle se retrouve dans les deux tables.
Jeu de test :
Les deux dernières insertions doivent être rejetées : l'id 3 existant dans l'entité frère T_BATEAU et l'id 5 n'existant pas dans l'entité mère. Mais cet exemple est incomplet car il faudrait créer ce même type de trigger dans la table T_BATEAU pour vérifier la présence de la clef dans la table père et vérifier son absence dans la table sur. De même qu'il serait souhaitable de gérer une suppression en cascade pour le père et éventuellement une modification de la valeur de la clef en cascade ! Bref, à vous de jouer... Sixième exemple - voici maintenant une association d'un genre particulier. L'association 0:0 ! Comment gérer une telle relation ? Comme à mon habitude un exemple concret est plus compréhensible : nous voici avec un texte à indexer mot pour mot, et pour cela nous devons classer chaque mot rencontré dans le texte dans une table T_MOT (MOT_MOT, MOT_REF, MOT_PAGE, MOT_LIGNE, MOT_OFFSET) avec la référence du texte, la page, la ligne et l'offset en nombre de caractère. Mais il serait absurde d'indexer tous les mots. C'est pourquoi une table T_MOT_NOIR(MNR_MOT) de mot indésirables (les mots "noirs") est créée, et l'on souhaite qu'aucun des mots indexé pour le texte ne soit un mot noir, ni qu'aucun mot noir ne se trouve dans les mots indexé. C'est donc bien une relation d'exclusion totale, telle que l'intersection des colonnes MOT_MOT de T_MOT et MNR_MOT de T_MOT_NOIR produise un ensemble vide, ou plus simplement que :
Soit toujours évaluée à vrai ! Un tel trigger n'est pas difficile à écrire :
Il faudrait d'ailleurs penser à écrire son réciproque dans la table T_MOT_NOIR empêchant ainsi l'insertion d'un mot noir pré existant dans la table T_MOT. On peut bien entendu tester un tel trigger avec le jeu d'essai suivant :
En conclusion nous pouvons dire que les triggers de la version 7 de SQL Server sont assez limités en ne permettent pas de gérer très finement les données. Ils ne fournissent pas un mécanisme pratique et simple lorsque l'on veut par exemple manipuler ligne à ligne et colonne par colonne la vailidité des données et les rectifier à la volée avant l'insertion définitive. Il semble que la version 2000 de SQL Server respecte plus la norme SQL 2 sur ce point. Septième exemple - dans une relation d'héritage, comment insérer dans une table fille alors que l'insertion dans la table mère est un pré requis ? Par exemple, nous avons une table des personnes, une table des clients et une table des employés. Ces tables sont construites de la sorte :
On ne peut donc pas insérer directement dans T_EMPLOYE_EMP, sauf à utiliser une vue et un trigger INSTEAD OF... Creation de la vue V_EMPLOYEE_EMP :
Dès lors on peut créer un trigger d'insertion dans cette vue qui va décomposer les éléments à insérer et injecter les données dans les deux tables :
Utilisation :
NOTA : voici le trigger de contrôle d'intégrité des bornes des arborescence exprimées sous forme intervallaire (voir l'article sur ce sujet) :
6. Cryptage du code, liaison au schema et recompilationENCRYPTION indique que SQL Server crypte l'entrée de la table système contenant le texte de l'instruction (procédure, fonction, trigger ou vue). L'utilisation de cet argument permet le confidentialité du code et évite la publication de la procédure dans le cadre de la réplication. C'est un moyen qui ne garantie pas qu'un utilisateur mal intentionné n'insère des données impropres. Mais cette technique permet de contraindre l'exécution de certains éléments aux seuls possesseurs d'un algorithme de vérification. Pour comprendre comment mettre en oeuvre un tel mécanisme, voici un exemple complet :
Voila comment certains éditeurs de progiciel se protègent des petits malins qui tente de "pourrir" leur base en y insérant des données sans passer par l'application ! RECOMPILE indique que SQL Server n'utilise pas le cache pour le plan de la procédure (ou de la vue). Elle sera donc recompilée à chaque l'exécution. Cela est conseillé lorsque vous utilisez des valeurs temporaires ou atypiques (aléatoires par exemple). SCHEMABINDING Indique qu'une fonction (vue ou index) est liée aux objets base de données auxquels elle fait référence. La fonction ainsi créée ne pourra être supprimée que si tous les objets base de données auxquels la fonction fait référence sont supprimés préalablement. 7. ANNEXE BIBLIOGRAPHIQUELivres : Transact SQL Programming - Kelvin Kline, Lee Gould & Andrew Zanevsky - O'Reilly Professionnal SQL Server 7 Programming - Robert Vieira - Wrox Inside Microsoft SQL Server 7.0 - Ron Soukup, Kalen Delaney, Microsoft Press SQL Server 7 - Marc Israel - Eyrolles SQL Server 7.0 - Stephen Wynkoop - Campus Press SQL Server DBA - Mark Spenik, Orryn Sledge - Campus Press SQL Server 2000 - Marc Israel - Eyrolles SQL Server au quotidien Expert - M. F. Garcia, J Reding, E. Whalen, A. Deluca - Microsoft Press Sites web : http://www.microsoft.com http://www.developpez.com/ http://www.multimania.com/lewisdj/sql.htm http://www.sqlservercentral.com/ http://www.sqlteam.com/
|
Copyright © 2004 Frédéric Brouard. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.