Discussion :

[Maren00]

Bonjour à tous,
Je suis confrontée à un problème d'appel d'une procédure stockée à partir d'une autre, qui elle appelle une 3ème.

[dbo].[P_TEST_P1] ==> [dbo].[P_TEST_P2]==> [dbo].[P_TEST_TABLE]

L'exécution de la procédure [dbo].[P_TEST_P2] qui appelle [dbo].[P_TEST_TABLE] fonctionne sans problème. Mais lorsque j'exécute [dbo].[P_TEST_P1], j'obtiens l'erreur:

"P_TEST_P2 Insert Error: Column name or number of supplied values does not match table definition."

Or je pense que ce n'est pas un problème de nom ou du nombre de colonne. Car il suffit que dans la procédure P_TEST_P1 je remplace P_TEST_P2 par P_TEST_TABLE et ça fonctionne. Mon problème est donc celui d'appel de procédure stockée au 3ème niveau.

Merci pour toute aide.

1. Procédure de base ([dbo].[P_TEST_TABLE])

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
CREATE PROCEDURE [dbo].[P_TEST_TABLE]
 
	@p_SqlMessageRetour	nvarchar(256) = '' output
AS
 
SET XACT_ABORT ON;
SET NOCOUNT ON;
 
BEGIN TRY
 
		CREATE TABLE #T_PERIODE(IdPeriode int,Mois nvarchar(20))
 
		INSERT INTO #T_PERIODE (IdPeriode,mois)	VALUES (1,'Janvier')
		INSERT INTO #T_PERIODE (IdPeriode,mois)	VALUES (2,'Février')
 
		SELECT * FROM #T_PERIODE		
 
		IF OBJECT_ID(N'[TEMPDB].[dbo].[#T_PERIODE]', N'U') IS NOT NULL DROP TABLE #T_PERIODE ;
 
	RETURN 0
 
END TRY
BEGIN CATCH
		SET @p_SqlMessageRetour=ISNULL(error_procedure(),'') + ' ' + ISNULL(error_message(),'');
		SELECT @p_SqlMessageRetour;
		RETURN ISNULL(error_number(),1);
END CATCH

1. Procédure de base ([dbo].[P_TEST_P2])

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
CREATE PROCEDURE [dbo].[P_TEST_P2]
	@p_SqlMessageRetour	nvarchar(256) = '' output
AS
 
SET XACT_ABORT ON;
SET NOCOUNT ON;
 
BEGIN TRY
 
		CREATE TABLE #T_PERIODE(IdPeriode int , Mois nvarchar(20))
 
		INSERT INTO #T_PERIODE EXECUTE [dbo].[P_TEST_TABLE] @p_SqlMessageRetour OUTPUT
 
		SELECT * FROM #T_PERIODE
 
		IF OBJECT_ID(N'[TEMPDB].[dbo].[#T_PERIODE]', N'U') IS NOT NULL DROP TABLE #T_PERIODE ;
 
	RETURN 0
 
END TRY
BEGIN CATCH
		SET @p_SqlMessageRetour=ISNULL(error_procedure(),'') + ' ' + ISNULL(error_message(),'');
		SELECT @p_SqlMessageRetour;
		RETURN ISNULL(error_number(),1);
END CATCH

1. Procédure de base ([dbo].[P_TEST_P1])

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
CREATE PROCEDURE [dbo].[P_TEST_P1]
	@p_SqlMessageRetour	nvarchar(256) = '' output
AS
 
SET XACT_ABORT ON;
SET NOCOUNT ON;
 
BEGIN TRY
 
		CREATE TABLE #T_PERIODE(IdPeriode int , Mois nvarchar(20))
 
		INSERT INTO #T_PERIODE EXECUTE [dbo].[P_TEST_P2] @p_SqlMessageRetour OUTPUT
 
		SELECT * FROM #T_PERIODE
 
		IF OBJECT_ID(N'[TEMPDB].[dbo].[#T_PERIODE]', N'U') IS NOT NULL DROP TABLE #T_PERIODE ;
 
	RETURN 0
 
END TRY
BEGIN CATCH
		PRINT 'TEST'
		SET @p_SqlMessageRetour=ISNULL(error_procedure(),'') + ' ' + ISNULL(error_message(),'');
		SELECT @p_SqlMessageRetour;
		RETURN ISNULL(error_number(),1);
END CATCH

[elsuket]

Bonjour,

Il suffit de ne pas CATCHer l'erreur comme vous l'avez fait, et on trouve :

Une instruction INSERT EXEC ne peut pas être imbriquée.

@++

[Maren00]

Bonjour elsuket et merci pour votre réponse.
Je reçois effectivement l'erreur selon laquelle l'instruction INSERT EXEC ne peut être imbriquée.
Comment peut on donc contourner ce problème?
Merci pour toute indication.

[elsuket]

Cela ne semble pas faisable à priori.

Pouvez-vous nous dire pourquoi vous avez besoin d'effectuer une telle implémentation ?
Également, pourquoi vous utilisez des tables temporaires (est-ce seulement pour l'exemple) ?
Ne pouvez-vous pas utiliser seulement qu'une seule procédure stockée ?

@++

[Maren00]

En fait, je suis obligée de faire une telle implémentation pour question de maintenance.
Voici à quoi ressemble mon architecture:
J'ai plusieurs procédures de 1er niveau de type [dbo].[P_TEST_P1] (P1_1, P1_2, P1_3, ...).
Ensuite, j'ai plusieurs procédures de 2ème niveau de type [dbo].[P_TEST_P2] (P2_1, P2_2, P2_3, ...).
Enfin des procédures de derniers niveau de type [dbo].[P_TEST_P3] (P3_1, P3_2, P3_3, ...)

• Les procédures de 3ème niveau retournent un résulat intermédiaire nécessaire pour l'exécution des procédures de 2ème niveau

• Les procédures de 2ème niveau retournent un résulat intermédiaire nécessaire pour l'exécution des procédures de 1er niveau

• Les procédures de 1er niveau retournent un résulat final

Si à chaque niveau, on n'avait qu' UNE ou à la limite 2 procédures, j'aurais écrit une seule procédure quit à dupliquer le code. Le malheur est que nous avons à chaque niveau plusieurs procédures et des possibilités de scénarios d'appel suivants:
P1_1==>P2_1==>P3_1
P1_2==>P2_1==>P3_3
P1_1==>P2_2==>P3_1
P1_3==>P2_1==>P3_1
P1_1==>P2_2==>P3_2
P1_3==>P2_3==>P3_1
P1_1==>P2_3==>P3_2
...
S'il me faut alors rammener mon architecture à un seule niveau, alors, ça sera bien fait pour moi pour la duplication du code, et par conséquent pour la maintenance.
D'autre part, les procédures intermédiaires (2ème et 3ème niveau) sont si complexes qu'il m'est impossible d'utiliser les fonctions qui aurait résolu le problème.

Merci

[elsuket]

Je crois surtout qu'il s'agit d'un problème de modélisation de votre base de données.
Dans la plupart des cas, si le modèle a été conçu dans les règles et avec parcimonie, toute requête s'exprime au moins assez simplement.

@++

[Maren00]

Bonsoir et merci pour votre réponse.
Je suis mal placée pour savoir si la base de données a été bien modélisée ou pas.
il s'agit d'une appli qui a été conçue depuis longtemps et je dois l'évoluer et la maintenir.
J'ai pu contourner mon problème en créant des tables de travail qui sont chargées à l'exécution de l'appli et de nouveau vidées à la fin. Ces tables contiennent ainsi les résultats des procédures de niveau 2 et 3.
Les procédures de niveau 1 accèdent UNIQUEMENT à ces tables de travail.
Merci pour votre aide