2009-06-26 8 views
1

Voici un problème lié à une procédure stockée (à l'aide de SQL Server 2005). Dans cette procédure stockée, elle appelle une autre procédure stockée qui place les données dans une table temporaire.Problème de procédure stockée SQL Server appelant une autre procédure stockée

INSERT INTO #tmpTable (Column1, Column2, Column3) 
EXEC psp_rptInsideStoredprocedure 2 

Cette procédure stockée à l'intérieur possède un paramètre de mode qui détermine quelles colonnes sont transmises. Dans ce mode (Mode2), seulement 3 colonnes sont perdues, lorsque cette procédure stockée à l'intérieur est utilisée pour un autre rapport (Mode1) 4 colonnes sont passées. Parfois, la procédure stockée parent se plaint d'essayer d'insérer la colonne 4 et parfois non.

Je sais que ça passe toujours en mode 2 mais c'est comme si SQL Server savait que parfois cette procédure stockée a passé 4 colonnes.

Des idées sur une solution?

Merci

Don

+0

L'affichage de la source de procédure "Inside" peut vous aider. –

+0

La table temporaire est-elle supprimée entre les invocations d'une même session? –

Répondre

0

enchaînant Daisy procédures stockées est généralement pas une bonne idée. Je supprimer l'appel au sproc et taper le t-sql pour exactement ce dont vous avez besoin. Si vous êtes vraiment en train d'appeler un autre sproc. Faire un nouveau sproc qui fait exactement ce dont vous avez besoin pour cette situation.

Il est tout au sujet de la Single Responsibility Principle

+4

Puis de nouveau - après avoir divisé le code en deux SProcs séparés peut-être juste à cause de la SRP! –

+1

Je ne suis pas d'accord. Créer des sprocs séparés ciblés qui font bien une chose spécifique est exactement ce que le SRP est tout. –

3

rendre la procédure de retour enfant toujours le même nombre et le type de colonnes, utilisez NULL si nécessaire. Si les résultats sont si différents pour les deux versions, que vous ne pouvez pas les combiner comme cela, vous devriez envisager de faire deux procédures différentes. Je ne fais que deviner votre procédure, mais vous pouvez créer une table temporaire #ResultSet et la remplir en fonction de votre paramètre type, mais toujours retourner toutes les colonnes, etc. Si vous renvoyez beaucoup de lignes, cela devient mauvais, comme la table temporaire est overhead. dans ce cas, assurez-vous que vos ensembles de résultats renvoient le même nombre de colonnes:

IF @version=1 
BEGIN 
    SELECT col1, col2, NULL FROM ... WHERE ... 
END 
ELSE 
BEGIN 
    SELECT col1, col2, col3 FROM ... WHERE ... 
END 

Puis, quand les deux parents l'appellent, acceptent toutes les colonnes, mais ils peuvent ignorer ce qu'ils ne ont pas besoin.

Questions connexes