Discussion :

[b_lob]

Bonjour,

j'ai lu la documentation sqlpro sur les triggers et je n'arrive pas à reproduire la fonction if update(nom de colonne)

mssql 2000

Voila le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
create trigger TRG_UPDATE on TABLE
for insert
as
if update(date)
insert into AUTRETABLE select * from INSERTED

Ce trigger fonctionne si je fais un insert dans la table "TABLE " avec ou sans date... et comme vous l'aurez compris, la table "AUTRETABLE " doit recuperer que les insert ayant une date.

Le mot clé update me laisse perplexe car il me fait penser a un update mais il s'agit bien d'un insert. J'ai essayé if insert(date) mais sans succès.

[Monstros Velu]

ben tu demandes si un champs a été updaté sur un trigger en insertion. A mon avis, quand un update un champ, c'est un trigger en update ;o)

si tu veux savoir si ton champ reçoit une valeur lors de l'insertion, tu peux tester voir s'il est null.

[NumaK]

Salut,

Tu peux faire plus simple en mettant ta condition dans le where

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
INSERT AUTRETABLE
SELECT
  *
FROM
  INSERTED
WHERE
  Date IS NOT NULL

Un conseil ... dans tes triggers, met toujours le code suivant au début (après AS)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET NOCOUNT ON

Ca évitera à SQL Server de renvoyer des messages sur le nombre de lignes affectées par les instructions du trigger au client (par client, j'entends ADO, ODBC, ...). Dans le cas d'ADO, ça pose un certain nbre de problèmes !

[b_lob]

Effectivement, c'est plus simple et ca tourne nickel.. Merci aussi pour l'astuce du nocount on.

Ceci dit je comprend pas comment ca fonctionne pour le script trouvé sur sqlpro. Le trigger gere a la fois l'update et l'insert et il utilise bien if update(colonne)...

[NumaK]

Il me semble qu'un IF UPDATE(...) est toujours vrai dans un trigger INSERT et vrai dans un trigger UPDATE à partir du moment où la colonne a été affectée.
Tous les cas suivants font que IF UDPATE(...) renvoie TRUE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
UPDATE Table SET Col=1
UPDATE Table SET Col=NULL
UPDATE Table SET Col=Col

Ceci dit, pour l'explication du script de SQLPro, il faut que tu nous le montres

[b_lob]

Je comprend mieux pourquoi mon trigger était toujours executé

voila le code de sqlpro

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
CREATE TRIGGER E_CLI_INS
       ON  CLIENT
       FOR INSERT, UPDATE
AS
-- inutile si pas d'update de la colonne visée
IF NOT UPDATE(CLI_TEL)
RETURN
-- requête de contrôle avec table d'insertion
SELECT CAST(REPLACE(CLI_TEL, '.', '') as DECIMAL(20))
FROM   INSERTED
-- rollback en cas d'erreur
IF @@Error <> 0
ROLLBACK TRANSACTION

Ce trigger gere a la fois les evenements d'insertion et de mise a jour.
Il formate le numéro de téléphone mais apparamment, il ne l'insère pas.
Et surtout si j'ai bien compris, il va s'executer pour toutes les insertions meme si CLI_TEL est nul et s'executer pour les mises a jour sauf si CLI_TEL est nul.


Est ce qu'il vaut mieux avoir un trigger pour chaque opération (Update, Delete, Insert) ou un trigger pour tous ?

[NumaK]

En fait, c'est un trigger de test que tu ne trouverais pas en production.

Dans le cas d'une insertion, IF UPDATE() renvoie effectivement toujours TRUE (j'ai qd même vérifié histoire de ne pas t'enduire d'erreur).

Ici, le trigger renvoie un curseur contenant les n° de téléphone formaté.
Donc si tu exécutes la requête

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

INSERT Client(...) VALUES(...)

dans l'analyseur de requêtes par ex., tu verras un curseur dans le grid du bas contenant le n° de téléphone inséré formaté.

Pour répondre à ta question, je préfère pour ma part avoir un trigger par type d'action (et même plusieurs triggers pour une même action, suivant un découpage fonctionnel); cela me semble plus souple à maintenir, et plus facile à comprendre pour le développeur/DBA qui me succèdera ...
En outre , tu ne peux pas avoir un trigger pour toutes les actions. L'action DELETE est forcément seule (elle référence la table logique DELETED, alors que les actions INSERT/UPDATE référencent la table logique INSERTED)

[Monstros Velu]

le trigger update référence les 2 tables logiques inserted et deleted.

[NumaK]

Oups ! Tu as complètement raison (et moi qui ne voulait pas l'enduire d'erreur)

[b_lob]

Merci beaucoup ! je suis moin enduis d'erreur maintenant

Dernière chose, est ce qu'il faut vraiment desactiver le chargement rapide d'un lot dts pour que les triggers soit déclanchés ?

Parce que la j'ai plus de deux heures d'importations...

[NumaK]

Je n'utilse pas les DTS, je fais tous mes imports de données avec BULK INSERT.
D'ailleurs, je me demande si l'option "Chargement rapide" dont tu parles pour les DTS n'exécute pas en fait un BULK INSERT en interne, auquel cas les triggers ne sont désactivées que si on en fait la demande explicite.