2010-02-04 14 views
8

J'ai une procédure stockée avec un paramètre de sortie int. Si je lance Profiler SQL Server, exécutez la procédure stockée via un code .Net, et capturer le RPC: événement terminé, le TextData ressemble à ceci:Paramètres de sortie de procédure stockée dans SQL Server Profiler

declare @p1 int 
set @p1=13 
exec spStoredProcedure @[email protected] output 
select @p1 

Pourquoi ça ressemble, il devient la valeur de la sortie paramètre avant d'exécuter la procédure stockée?

+0

? parce que c'est comme ça? Où est la question? –

+0

Eh bien, la façon dont il est affiché donne l'impression qu'il devine magiquement la valeur du paramètre de sortie avant d'exécuter la procédure stockée. Ce n'est évidemment pas la séquence des commandes en cours d'exécution, donc je me demandais juste pourquoi il est affiché de cette façon. –

Répondre

5

La classe d'événement RPC: Completed indique qu'un appel de procédure à distance a été effectué. Le paramètre de sortie est donc connu à ce moment-là. Voyez si le tracé du RPC: Started vous montre ce que vous attendez.

+0

Ok, je vois, dans l'événement RPC: Started, la variable @ p1 est définie sur NULL. J'ai du bon sens, je suppose. –

+0

Je suis convaincu qu'il s'agit d'un bug (et ajouté une réponse à cet effet) - avez-vous des indications que c'est un comportement prévu? Je n'ai pu trouver aucune documentation de toute façon. – Tao

4

C'est, peu importe comment vous le regardez, un bug. L'intention du SQL Profiler "TextData" est de permettre à quelqu'un de comprendre et de répéter l'appel de procédure stockée. Dans ce cas, l'exécution de ce T-SQL peut vous donner un résultat complètement différent si la procédure spStoredProcedure a une logique dépendant de la valeur d'entrée du paramètre @OutParam, où la valeur de "13" était significative . Il est facile de voir comment cela peut être pratique (vous permet de voir les valeurs de sortie de l'appel de proc, ce qui aurait autrement besoin de l'événement "RPC Output Parameter"), mais c'est effectivement un "mensonge" quant à ce que l'équivalent T-SQL a été exécuté. CONNEXION: Je viens de rencontrer un article de l'équipe du service clientèle et de l'assistance de Microsoft - à propos d'un autre cas où la conversion de BinaryData de l'événement RPC: Completed en une valeur TextData affichable aboutit à une reproduction inexacte de l'appel RPC d'origine. temps les questions de codepage:
http://blogs.msdn.com/b/psssql/archive/2008/01/24/how-it-works-conversion-of-a-varchar-rpc-parameter-to-text-from-a-trace-trc-capture.aspx

MISE à JOUR: en expérimentant avec cela, je trouve une autre particularité du comportement - le profileur n'utilisera cette configuration initiale incorrecte si la valeur d'entrée pour ce paramètre, dans l'appel RPC, était Null . Si une valeur non nulle était fournie (et que le paramètre, dans .Net SqlClient, avait la direction "InputOutput"), alors ce SET initial contient la vraie valeur d'entrée, et non la valeur de sortie résultante. Mais si l'entrée était nulle, la valeur de sortie est définie à la place. Cette observation prend en charge la notion qu'il s'agit simplement d'un bogue de gestion null dans la conversion d'affichage RPC-TSQL du profileur.

Questions connexes