Discussion :

[Maysa56]

Bonjour à tous,

j'ai une table qui a plusieurs colonnes nommées ainsi POIDS_1, POIDS_2 etc.... j'aimerai faire un trigger si modification d'une de ces colonnes.

1^re question : est-il possible de savoir quelles colonnes ont été modifées ? et traiter uniquement celles modifiées ?
2^e question : comme je ne sais pas combien j'ai de variables POIDS_xx comment boucler sur ces variables ?

merci d'avance pour votre aide.
Maysa

[StringBuilder]

1/ Le seul moyen fiable de savoir ce qui a été modifié, c'est de comparer les pseudo tables deleted (valeurs avant mise à jour) et inserted (valeurs après mise à jour). En effet, ta requête UPDATE peut affecter 25 lignes et ne modifier effectivement que 15 d'entre elles, donc seulement 5 reçoivent une valeur différente dans une colonne POIDS_x.

2/ Mise à part faire du SQL Dynamique dans un curseur (tous deux très fortement déconseillés) pas de moyen de modifier des colonnes dont on ne connait pas le nom à l'avance. En revanche, avoir des colonnes POIDS_xx indique un schéma particulièrement mal modélisé. Tu devrais avoir une table fille avec la liste des différents poids relatifs à ton entité. C'est d'autant plus vrai si tu ne connait pas à l'avance le nombre de poids. Ton modèle ne peut être correct que si cette liste est figée et que tu es censé avoir une valeur dans chaque colonne pour chaque ligne (par exemple poids brut/poids net; ou "poids matière grasse/poids fibres/poids sucre" (et encore là la liste peu rapidement devenir incontrôlable)

[SQLpro]

1/ Le seul moyen fiable de savoir ce qui a été modifié, c'est de comparer les pseudo tables deleted (valeurs avant mise à jour) et inserted (valeurs après mise à jour).

Non... La fonction UPDATE dans le déclencheur est là pour ça :
https://learn.microsoft.com/en-us/sq...l-server-ver16

A +

[StringBuilder]

Non... La fonction UPDATE dans le déclencheur est là pour ça :
https://learn.microsoft.com/en-us/sq...l-server-ver16

A +

En effet, j'avais commencé à l'orienter vers ça mais :

If a trigger applies to a column, the UPDATED value will return as true or 1, even if the column value remains unchanged. This is by-design, and the trigger should implement business logic that determines if the insert/update/delete operation is permissible or not.

Plus ça :

IF UPDATE returns the TRUE value in INSERT actions because the columns have either explicit values or implicit (NULL) values inserted.

J'aurais tendance à dire que ça filtre pas "énormément", et il faudra de toute façon comparer inserted et deleted ensuite.
Du coup j'ai pas trouvé cette fonction très utile.

Aussi, l'article n'indique pas si le paramètre doit obligatoirement être la colonne ou s'il peut aussi être une chaîne de caractères contenant le nom de la colonne. Dans le premier cas, exit le SQL dynamique. Mais bon, de base, il vaut mieux de toute façon ne pas en faire

[SQLpro]

...

Aussi, l'article n'indique pas si le paramètre doit obligatoirement être la colonne ou s'il peut aussi être une chaîne de caractères contenant le nom de la colonne. Dans le premier cas, exit le SQL dynamique. Mais bon, de base, il vaut mieux de toute façon ne pas en faire

Dans le pire des cas tu peut passser un masque binaire des positions ordinales des colonnes modifiées avec :
COLUMNS_UPDATED


A +

[Maysa56]

1/ Le seul moyen fiable de savoir ce qui a été modifié, c'est de comparer les pseudo tables deleted (valeurs avant mise à jour) et inserted (valeurs après mise à jour). En effet, ta requête UPDATE peut affecter 25 lignes et ne modifier effectivement que 15 d'entre elles, donc seulement 5 reçoivent une valeur différente dans une colonne POIDS_x.

2/ Mise à part faire du SQL Dynamique dans un curseur (tous deux très fortement déconseillés) pas de moyen de modifier des colonnes dont on ne connait pas le nom à l'avance. En revanche, avoir des colonnes POIDS_xx indique un schéma particulièrement mal modélisé. Tu devrais avoir une table fille avec la liste des différents poids relatifs à ton entité. C'est d'autant plus vrai si tu ne connait pas à l'avance le nombre de poids. Ton modèle ne peut être correct que si cette liste est figée et que tu es censé avoir une valeur dans chaque colonne pour chaque ligne (par exemple poids brut/poids net; ou "poids matière grasse/poids fibres/poids sucre" (et encore là la liste peu rapidement devenir incontrôlable)

Je suis totalement d'accord avec toi, le modèle n'est pas bon, mais j'en ai malheureusement hérité. je suis justement en train de faire la migration de cette base de données vers une autre mieux construite, et je dois donc récupérer tous les champs.
Merci à tous pour vos conseils.

[Maysa56]

Dans le pire des cas tu peut passser un masque binaire des positions ordinales des colonnes modifiées avec :
COLUMNS_UPDATED


A +

Merci Fred, Je regarde ça.

[armel1990]

Bonjour a tous ,
je m'excuse déjà de m’interférer dans votre discussion . en fait je suis nouveau même si mon compte ne l'ait pas.
je voudrais savoir comment recevoir une alerte par mail quand un trigger se declanche .
merci !

[StringBuilder]

Ca fait partie des exemple de base de la page de documentation des triggers...
https://learn.microsoft.com/en-us/sq...l-server-ver16

Par contre pour ma part c'est pas forcément une bonne idée de faire envoyer des mails par SQL Server, surtout dans un trigger.
En effet, surtout si vous passez par un SMTP distant, la latence est de l'ordre de plusieurs dixièmes de secondes pour que l'envoi de mail rende la main.
=> Ca va complètement pourrir les perfs du serveur.
Aussi, si l'envoi du mail plante (hôte non disponible, etc.) ça va faire planter le trigger et annuler la transaction... Ca me semble une lourde punition pour ne pas avoir pu envoyer un mail informatif.

Perso dans ces cas, je préfère :
- soit gérer une table d'alerte, dans laquelle puise un programme qui va effectivement dispatcher (et regrouper) les alertes à qui de droit
- soit gérer l'envoi du compte rendu des actions au programme appelant : y'a que lui qui sait si c'est bloquant ou non d'avoir la notification

[armel1990]

Bonsoir StringBuilder ,
merci pour le conseil .
pourrais tu m'aider a mettre cela en placec si ton temps te le permet biensur ?
merci d'avance

[StringBuilder]

Au lieu de faire envoyer le mail par le trigger, il suffit de lui faire écrire une ligne d'information dans une table dédiée aux notifications.

Ensuite, un programme sélectionne à interval régulier les notifications non déjà envoyée, les envoie, et les flag pour ne plus les prendre en compte une seconde fois.

[SQLpro]

Pour information l'envoi d'email via database mail intégré à SQL Server fait cela automatiquement :
1) le mail est intégré à une file d'attente de service broker et le trigger termine son action. C'est juste un iNSERT dans une table système optimisée pour cela.
2) service broker scrute au fil de l'eau la table interne pour envoyer les emails
3) un journal d'envoi est disponible pour savoir si l'envoi est effectif ou non...

A +

[KyoshiroKensei]

Bonjour,

Pour l'envoi de mail, il suffit de paramétrer un compte et un profil dans SQL MAil puis d'utiliser sp_send_dbmail. Je vous recommande de ne pas faire directement l'appel de sp_send_dbmail. Faites plutot une procedure stockée exécutant sp_send_dbmail.

Cela fonctionne très bien comme le dit SQLPRO.

[armel1990]

Merci a tous ,
StringBuilder ,SQLpro,KyoshiroKensei merci pour votre aide .
je vais faire des recherches par rapport a ce que vous avez dit et voir si je pourrai mettre çà en place.
En fait J'ai un profil réseau et telecom du coup cote BD c'est plutôt les bases . Mais j'avoue avoir beaucoup appris depuis 2 mois sur la plateforme alphorm .
je vais essayer d'avancer et si y'a un blocage je reviendrai vous déranger encore un peu .
Bonne continuation !!!

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

J'avais fait ça, un envoi de courriels dans un trigger pour un client.
C'était important pour lui d'être prévenu pour un statut précis.
Mais il recevait tellement de messages (>30/jour) qu'il m'a rapidement demandé de le désactiver et d'avoir seulement un rapport par jour...

[armel1990]

Bonsoir AaâÂäÄàAaâÂäÄàAaâ ,
merci .
dans mon cas il va peut être se déclencher une fois par jours ou pas du tout .