Discussion :

[spud19]

Bonjour,

J'ai un petit souci avec mes triggers.

Pour information, et si ça peut aider. Je suis en C# et j'utilise llblgen pour la génération du code.

Donc j'ai ma classe A

Je fais

Code C :

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

1
2
3
A.Label1 = 1;
A.Label2 = 2;
datacontext.Save();

Mon trigger est déclenché deux fois. une fois pour le changement du label1, une seconde fois sur le changement du label2.

Mon trigger ressemble à ça :

Code :

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

1
2
3
4
5
6
CREATE TRIGGER [dbo].[after_update] 
    ON [dbo].[MYTABLE]
    AFTER UPDATE
    AS 
    BEGIN
    EXEC storeProc

Comment faire pour que le trigger ne soit fired qu'une seule fois?

En vous remerciant.

[hmira]

Comment faire pour que le trigger ne soit fired qu'une seule fois?

Bonjour,

Avant de chercher inintelligemment une solution pour que le trigger ne se déclenche qu'une seule fois, il faut d'abord comprendre ce qui se passe !

Ci-dessous 2 questions :

1 - Est-ce ton code c# génère au niveau Serveur de base de données, en l'occurrence SQL Server, 2 instructions update ; une première instruction update pour "A.Label1 = 1" puis une 2ème instruction update pour "A.Label2 = 2" ?
Si Oui c'est normal que le trigger se déclenche 2 fois et tu ne pourras pas faire grand chose sans l'ajout d'artifices complexes qui finira par rendre ton code T-SQL complètement abscons.

2 - Est-ce que au sein même de la procédure storeProc invoquée dans le trigger [dbo].[after_update] tu re-modifies à nouveau directement ou indirectement la table [dbo].[MYTABLE] ?
Si oui, là il y a des solutions pour limiter la réentrance et la récursivité des triggers.

Pour analyser ce qui se passe au niveau Serveur, un moyen simple est d'utiliser l'outil SQL Server Profiler.

A+

[Invité]

DéclEncher !
Merci.

[hmira]

DéclEncher !

Yes !

J'ai vu beaucoup de projets où l'utilisation abusive des déclencheurs finit par revenir très cher !
Les applications deviennent des usines à gaz, incompréhensibles et inmaintenables. Certaines finissent même à la poubelle !
On peut effectivement parler de DéclenCher !

PS : A l’inverse, j’ai vu d’autres projets où il est stipulé en clair, à destination des développeurs, que l’utilisation des déclencheurs est strictement interdite !

A+

[spud19]

Bonjour,

1 - Est-ce ton code c# génère au niveau Serveur de base de données, en l'occurrence SQL Server, 2 instructions update ; une première instruction update pour "A.Label1 = 1" puis une 2ème instruction update pour "A.Label2 = 2" ?
Si Oui c'est normal que le trigger se déclenche 2 fois et tu ne pourras pas faire grand chose sans l'ajout d'artifices complexes qui finira par rendre ton code T-SQL complètement abscons.

2 - Est-ce que au sein même de la procédure storeProc invoquée dans le trigger [dbo].[after_update] tu re-modifies à nouveau directement ou indirectement la table [dbo].[MYTABLE] ?
Si oui, là il y a des solutions pour limiter la réentrance et la récursivité des triggers.

Pour analyser ce qui se passe au niveau Serveur, un moyen simple est d'utiliser l'outil SQL Server Profiler.

A+

1) Il n'y a qu'un entitystate = modified. A priori je dirais donc non. Mais je vais vérifier demain avec SQL server profiler.
2) Je pense l'avoir déjà pris en compte, mais peut-être pas de manière optimal. Que vois tu comme solution pour éviter ce genre de soucis?

En te remerciant.

[hmira]

Bonjour,

1) Il n'y a qu'un entitystate = modified. A priori je dirais donc non. Mais je vais vérifier demain avec SQL server profiler.

Je suis désolé, mais tu n'as répondu en clair à aucune de mes questions !
Ici c'est un forum SQL Server. Ici, ce n'est pas un Forum C#, Outils de développent et autre ORM llblgen etc ; même si je reconnais que les choses sont liées et que, lorsqu'on est confronté à un problème on est pressé de trouver une solution, et ce, sans essayer de faire la distinction entre les différentes composantes.
Par exemple la phrase "Il n'y a qu'un entitystate = modified" n'évoquera peut-être pas grand chose pour certains (même pour certains experts SQL Server). Essaye donc de te contenter de décrire ce qui se passe au niveau de SQL Server et uniquement au niveau SQL Server. D'aucuns diront de manière rustre "le reste on s'en branle les c." !

2) Je pense l'avoir déjà pris en compte, mais peut-être pas de manière optimal. Que vois tu comme solution pour éviter ce genre de soucis?

Là encore, tu ne réponds pas à la question ? Est-ce OUI ou NON tu remodifies la table dans le déclencheur ?

Si le problème provient de l'imbrication et de la récursivité des déclencheurs, ce dont on est pas sûr, au vu de tes réponses !, tu peux essayer ceci :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CREATE TRIGGER dbo.after_update 
ON dbo.MYTABLE
AFTER UPDATE 
AS 
BEGIN
 
	SET NOCOUNT ON ; 
 
	IF ( ( SELECT TRIGGER_NESTLEVEL ( ( SELECT g.object_id
										FROM sys.triggers g with (nolock) 
										INNER JOIN sys.tables t with (nolock) 
										 on t.object_id = g.parent_id
										INNER JOIN sys.schemas s with (nolock) 
										 on s.schema_id = t.schema_id 
										WHERE s.name = N'dbo' 
										AND t.name = N'MYTABLE' 
										AND g.name = N'after_update'), 'AFTER', 'DML' ) ) > 1 ) 
	BEGIN 
	 -- On ne fait rien ! 
	 RETURN 
	END; 
 
 --- Ici la suite de ton déclencehur ... 
 -- ..... 
 
END; 
GO

PS : Il s'agit d'une provocation amicale et volontaire de ma part, n'y vois aucune agressivité. Ici c'est un forum d'échange et d'entraide .

A+