[TSQL] Problème exécution procédure stockée

Version imprimable

Bonjour à tous !

Voici mon problème : Je souhaite mettre à jour une table A en fonction d'une table B uniquement si les données contenu dans A diffères de celle de B.
J'ai lu qu'il n'était pas conseillé de mettre à jour une table à l'aide d'une procédure stockée mais étant néophyte en l matière je n'ai pas trouvé d'autre solution...
Voici mon code :

Code:

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
 
 
ALTER PROCEDURE [dbo].[PS_RESTORE_PARAM_PROD] 
	-- Add the parameters for the stored procedure here
	@IdBase bigint 
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;
	DECLARE @Paragraphe varchar(50), @Variable varchar(50), @Valeur varchar(254), @Memo varchar(MAX), @Row uniqueidentifier, @IdBase_Connexion bigint
 
	DECLARE curseur_save CURSOR FOR
	SELECT Paragraphe, Variable,Valeur, Memo, Rowguid, Id_Base from dbo.Connexion_Serveur where Id_Base = @IdBase
 
	OPEN curseur_save
 
	FETCH curseur_save into @Paragraphe,@Variable, @Valeur, @Memo, @Row, @IdBase_Connexion
 
	WHILE @@FETCH_STATUS = 0
	BEGIN
 
		DECLARE @ParagraphePROD varchar(50), @VariablePROD varchar(50), @ValeurPROD varchar(254), @MemoPROD varchar(MAX), @RowPROD uniqueidentifier
		DECLARE curseur_PROD CURSOR FOR
		SELECT Paragraphe, Variable,Valeur, Memo, Rowguid from [ATH].[dbo].[CONNEXION_SERVEUR]
 
		OPEN curseur_PROD
 
		FETCH curseur_PROD into @ParagraphePROD,@VariablePROD, @ValeurPROD, @MemoPROD, @RowPROD
 
		WHILE @@FETCH_STATUS = 0
		BEGIN
 
			IF @Row = @RowPROD 
			BEGIN
				IF @Paragraphe != @ParagraphePROD
				SET @ParagraphePROD = @Paragraphe
 
				CLOSE curseur_PROD
				DEALLOCATE curseur_PROD
			END
 
		END
 
	END
 
END
CLOSE curseur_save
DEALLOCATE curseur_save

Je m'excuse d'ors et déjà auprès de ceux qui vont lire mon code car ça risque de leur faire mal aux yeux :lol:
Et si vous souhaitez plus de précision n'hésitez pas à me faire signe

Cordialement,

21/06/2016, 12h39
al1_24

Je pense que la commande MERGE devrait répondre de manière beaucoup plus élégante et efficace à ton besoin.
21/06/2016, 14h30
Heisenberg5625

En effet ça me semble bien mieux au première abord.
Je vais essayer ça, merci bien.
21/06/2016, 15h07
aieeeuuuuu

Bonjour,

Juste une précision sur ce point :

Citation:

Envoyé par Heisenberg5625

J'ai lu qu'il n'était pas conseillé de mettre à jour une table à l'aide d'une procédure stockée

Ce n'est pas le fait d'utiliser une procédure stockée, ce qui est au contraire plutôt une bonne pratique.
Ce qui est déconseillé, c'est d'utiliser des curseurs comme vous le faites. Ce ceux eux qui nuisent aux performances dans votre cas.

Merci pour cette précision aieuuuu.

J'ai essayé le MERGE mais j'ai une SQLException qui est levée du côté de mon application : "Une exception non gérée du type 'System.Data.SqlClient.SqlException' s'est produite dans System.Data.dll

Informations supplémentaires : La cible d'une instruction MERGE ne peut pas être une table distante, une vue distante ou une vue sur des tables distantes."

Voici le MERGE que j'ai fait :

Code:

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
 
USE [Migration_Donnees]
GO
/****** Object:  StoredProcedure [dbo].[PS_RESTORE_PARAM_PROD]    Script Date: 20/06/2016 16:40:01 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:		<Author,,Name>
-- Create date: <Create Date,,>
-- Description:	<Description,,>
-- =============================================
ALTER PROCEDURE [dbo].[PS_RESTORE_PARAM_PROD] 
	-- Add the parameters for the stored procedure here
	@IdBase bigint
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;
 
	CREATE TABLE #Con ([Paragraphe] varchar(50), [Variable] varchar(50), [Valeur] varchar(254), [Memo] varchar(MAX), [Rowguid] uniqueidentifier, [Id_Base] bigint)
	BEGIN
		INSERT INTO #Con
		([Paragraphe], [Variable], [Valeur], [Memo], [Rowguid], [Id_Base])
		SELECT
		[Paragraphe], [Variable], [Valeur], [Memo], [Rowguid], [Id_Base]
		FROM
		[dbo].[Connexion_Serveur]
		WHERE Id_Base = @IdBase
	END
	BEGIN
 
		MERGE [ATH].[dbo].[CONNEXION_SERVEUR] as prod
		USING #Con
		ON (prod.rowguid = #Con.Rowguid)
		WHEN MATCHED THEN
		UPDATE SET prod.Paragraphe = #Con.paragraphe;
 
	END
END

Bonjour,

Il me semble que le using ne s'utilise qu'avec une requête.
Code:

1 2 3 4 5 6 7 MERGE [ATH].[dbo].[CONNEXION_SERVEUR] as T USING ( SELECT * FROM #Con ) AS S ON T.rowguid = S.Rowguid WHEN MATCHED THEN UPDATE SET Paragraphe = S.paragraphe;
Par contre je ne comprends pas. Dans la première version il y a 2 curseurs qui s'imbriquent, comment 1 seul merge? (vu le code, un update devrait suffir même)

Sinon, il est possible de se passer de la #Con en utilisant la requête qui la constitue dans la source du merge.
Code:

1 2 3 4 5 6 7 8 9 10 MERGE [ATH].[dbo].[CONNEXION_SERVEUR] as T USING ( SELECT [Paragraphe], [Variable], [Valeur] , [Memo] , [Rowguid] , [Id_Base] FROM [dbo].[Connexion_Serveur] WHERE Id_Base = @IdBase) AS S ON T.rowguid = S.Rowguid WHEN MATCHED THEN UPDATE SET Paragraphe = S.paragraphe;
Cordialement,

28/06/2016, 11h06
Heisenberg5625

Bonjour,

En effet le using s'utilise que dans une requête et un UPDATE suffit.

Merci pour vos réponses !

Bonjour,

Attention avec les requêtes MERGE :

- MERGE donne l'impression que le traitement se fait d'un seul tir, comme on le pense avec INSERT, UPDATE ou DELETE. Or intrinsèquement, le moteur réalise les opérations une par une;
- Si la table cible du MERGE a des déclencheurs, et que le déclencheur peut s'exécuter sur plus d'un type de DML (ex FOR INSERT, UPDATE), le déclencheur s'exécute plusieurs fois, ce qui prouve d'ailleurs ce qui est ci-dessus :
Code:

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 CREATE TABLE zeTable ( i tinyint ) GO INSERT INTO zeTable (i) VALUES (4) CREATE TRIGGER TR_A_IU_zeTable ON zeTable FOR INSERT, UPDATE AS BEGIN SET NOCOUNT ON PRINT 'Entering the trigger' IF EXISTS (SELECT * FROM inserted) AND NOT EXISTS (SELECT * FROM deleted) BEGIN PRINT 'Processing INSERT - ' + CAST(SYSDATETIME() AS char(27)); END IF EXISTS (SELECT * FROM inserted) AND EXISTS (SELECT * FROM deleted) BEGIN PRINT 'Processing UPDATE - ' + CAST(SYSDATETIME() AS char(27)); END IF NOT EXISTS (SELECT * FROM inserted) AND EXISTS (SELECT * FROM deleted) BEGIN PRINT 'Processing DELETE - ' + CAST(SYSDATETIME() AS char(27)); END END GO MERGE INTO dbo.zeTable AS TGT USING ( SELECT 0 AS i UNION ALL SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 UNION ALL SELECT 6 ) AS SRC ON SRC.i = TGT.i WHEN MATCHED THEN UPDATE SET i = SRC.i WHEN NOT MATCHED BY TARGET THEN INSERT(i) VALUES (SRC.i) WHEN NOT MATCHED BY SOURCE THEN DELETE;
On a :

Citation:

Entering the trigger
Processing INSERT - 2016-06-28 14:19:57.4692079
Entering the trigger
Processing UPDATE - 2016-06-28 14:19:57.4692079

Attention donc à bien tester, notamment la concurrence.
Il est possible que dans certaines situations de concurrence d'exécution du MERGE, on doive sérialiser son exécution, soit avec HOLDLOCK, soit avec SET TRANSACTION ISOLATION LEVEL SERIALIZABLE.

@+ ;)