Discussion :

[gonsk]

Bonjour à tous,

Ce message car je bloque sur un problème, qui semble pourtant simple mais qui me rends fou.

j'ai un trigger after insert qui fait un insert dans une table. puis qui lance une procédure stocké. cette procédure stockée fait un simple BCP pour écrire mes données dans un fichier.

l'insertion dans la table marche sans problème.

si j’exécute ma procédure stocké manuellement ou via un job SQL agent. pas de soucis.

par contre si j’exécute a la fin du trigger ma procédure stockée. Cela agit comme si la procédure stocké ne voyait pas les lignes insérées dans le trigger.

en gros :
Run 1 => la ligne A est inséré. le trigger écrit bien la ligne dans ma table. le bcp agit comme s'il ne trouvait pas de réponse
Run 2 => La ligne B est inséré. le trigger écrit bien la ligne dans la table . le bcp fonctionne mais ne retourne comme résultat que la ligne A


mon trigger

Code :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
CREATE TRIGGER [dbo].[matltran_STE_AfterInsert]
ON [dbo].[matltran_mst]
AFTER INSERT
AS
   IF @@ROWCOUNT = 0 RETURN
 
   SET NOCOUNT ON
 
	BEGIN
 
 
	DECLARE @site as SiteType
 
	SELECT top 1 @site = site from parms_mst
	EXEC SetSiteSp @site,null
 
	DECLARE @sessionid				uniqueidentifier	= NEWID()
 
 
 
		----------------------------------------------------------------------------------------------------
		-- insertion dans la table temporaire des données inséré dans matltran - article no serialisé
		----------------------------------------------------------------------------------------------------
 
		insert into dbo.STE_EtiqReception (
			trans_num
			,item
			,lot
			,whse
			,loc
			,trans_date
			,qty
			,ref_num
			,LocRang1
			,LocARRCP
			,printed
			,etiq
			,sessionid
			)
 
		SELECT 
			i.trans_num
			, i.item
			, i.lot
			, i.whse
			, i.loc
			, i.trans_date
			, i.qty
			, i.Ref_num 
			, l.loc
			,'ARRCP'
			,'NO'
			, case
			when i.loc ='CTRL' then 'CTRL'
			else 'STD'
			end
			, @sessionid
			FROM inserted as i 
			 left outer join item_mst as a on  i.site_ref= a.site_ref and i.item = a.item
			 left outer join itemloc_mst as l on i.site_ref = l.site_ref and a.item = l.item
			 where i.trans_type='R' and i.ref_type='P' and a.serial_tracked='0' and l.rank='1'
 
 
	END
 
	If exists ( select 1 from STE_EtiqReception  where sessionid = @sessionid)
		BEGIN
		exec STE_Rpt_EtiquetteReception --@sessionid
		END
 
 
 
	RETURN
 
 
 
 
 
GO

ma SP :

Code :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
CREATE    PROCEDURE [dbo].[STE_Rpt_EtiquetteReception]
AS
 
SET NOCOUNT ON
 
DECLARE @site as SiteType
 SELECT top 1 @site = site from parms_mst
 EXEC SetSiteSp @site,null
 
 
  -- declaration des variables gestion des erreurs
DECLARE
@Severity		Int
,@MessError         nvarchar(40)		
,@MessNotif         nvarchar(40)
 
 
 ---SETS
SET @Severity = 0
SET @MessError = ''
SET @MessNotif = ''
 
 
 
--------********************************************************************
--------    CREATION de la ligne données   Masque STD
--------********************************************************************
 
if exists (select 1 from dbo.STE_EtiqReception where printed = 'NO')
 
	BEGIN
 
		declare
		 @DATEFIC						nvarchar(14)		= Format(getdate(), N'yyMMddHHmmss')
		,@lignedata						varchar(8000)
		,@movefile						varchar(8000)
		,@DBartender					varchar(100)	= '\\emea\emeashares\Bordeaux\DONNEES TECHNIQUES\Etiquettes_CB\50)DossierEtiquettesCB\BARTENDER\'
		,@DSetting						varchar(20)		='Settings\'
		,@Dtrigger						varchar(20)		='trigger'
		,@sql	nvarchar(max)
		,@execSQL	varchar(8000)
		,@Copyfile	varchar(4000)
		,@sessionid						uniqueidentifier  = newid()
 
 
 
		--------********************************************************************
		--------    CREATION de la ligne données   Masque STD
		--------********************************************************************
 
 
		if exists (select 1 from dbo.STE_EtiqReception where printed = 'NO' and loc <> 'CTRL')
 
			BEGIN
 
				SET @sql= '
				SELECT 
						 item
						+ '';''
						+ isnull(replace(lot,'' '',''''),'''')
						+ '';''
						+ whse
						+ '';''
						+ loc
						+ '';''
						+ Format(trans_date, N''dd-MM-yyyy'')
						+ '';''
						+ cast(cast (qty as decimal (10,3)) as nvarchar)
						+ '';''
						+ Ref_num
						+ '';''
						+ isnull(replace(ser_num,'' '',''''),'''')
						+ '';''
						+ locrang1
						+ '';''
						+ locarrcp
				 FROM ' + DB_NAME() + '.dbo.STE_EtiqReception
				 where printed=''NO'' and loc <> ''CTRL'''
 
 
				--Générer le fichier d export
 
				SET @execSQL = 'bcp "' + REPLACE(REPLACE(REPLACE(@sql,char(10),''),char(13),''),char(9),'') +'" queryout "'+  @DBartender + @DSetting + 'std_' + cast(@sessionid as varchar(40)) + '.dat" -c -T'
 
				select @execSQL
				exec master..xp_cmdshell @execSQL
 END
END
GO

[SQLpro]

C'est tout à fait normal. Un déclencheur permet de placer du code au moment de la transaction (INSERT, UPDATE, DELETE). Les données ne sont donc pas encore validées par un COMMIT. Tout utilisateur externe (et BCP en est un) ne peut en aucun cas voir les données en cours de modification. Ceci explique pourquoi le BCP renvoie la ligne A lorsque vous insérer la ligne B, car la ligne A a été validée !

D'autre part, il est hautement stupide de lancer des traitements lourds dans un déclencheur, justement parce que vous êtes au sein de la transaction, donc les données sont verrouillée à l'usage exclusif du déclencheur... Donc tout traitement qui prend du temps, bloque tout les autres utilisateurs aussi longtemps que le traitement dure !

Enfin, le code de votre déclencheur est faux... En effet, vous supposez que le déclencheur ne voit qu'une ligne de la table ce qui est faux. Un déclencheur ne se déclenche qu'une seule fois quelque soit le nombre de ligne manipulée dans l'ordre SQL qui l'a déclenché...

CONSEIL : votre manière de faire est totalement inadaptée. Récrivez votre traitement de manière à le rendre asynchrone. par exemple en utilisant une table tampon et un travail de l'Agent qui se déclenche toutes les 10 secondes par exemple.

A +

[gonsk]

merci d'avoir pris le temps de me répondre.


Effectivement actuellement mon script est déclenché de façon asynchrone via un agent qui se déclenche toutes les 10 sec. Mais j'avais l'intention d'améliorer ce script pour le lancer plus rapidement. (disons que mon client aimerait attendre le moins possible pour avoir son étiquette imprimé.)

mais si je comprends bien. ce n'est pas une bonne idée déclencher un traitement dans un trigger car cela lock l'enregistrement pendant le traitement. je pensais que dans un trigger "after insert" les données étaient présente dans la table.

donc en gros il me reste si vraiment je veux gagner du temps. d'envoyer les données "inserted" directement dans la sp. ou de jouer sur le delai de déclenchement de l'agent.

ps : il y a quelque chose a savoir ou a anticiper quand on lance un agent toutes les 10 secondes pendant 10h par jours ?


ps2 : je sais bien qu'un inserted peut avoir plusieurs lignes. mais la c'est un script de test ou je sais qu'il n'y a qu'une ligne insérée.

encore merci

[SQLpro]

Rien ne vous empêche de descendre à moins de 10 secondes. Testez 3.

A +

[gonsk]

je suis passé à 5 sec.

merci pour ces infos