これは、どのように見てもバグです。SQLプロファイラー「TextData」の目的は、誰かがストアドプロシージャの呼び出しを理解して繰り返すことができるようにすることです。この場合、プロシージャにパラメータの入力値に依存するロジックがあり、その値「13」が入力値として何らかの意味を持っていれば、このT-SQLを実行するとまったく異なる結果が得られる可能性があります。spStoredProcedure@OutParam
それがどのように便利であるかを理解するのは簡単です(そうでなければ「RPC出力パラメーター」イベントで行う必要があるproc呼び出しの出力値を確認できます)が、それは事実上、Tが何であるかについての「嘘」です。 -同等のSQLが実行されました。
関連:マイクロソフトカスタマーサービスおよびサポートチームからの記事に出くわしました-RPC:CompletedイベントのBinaryDataを表示可能なTextData値に変換すると、元のRPC呼び出しが不正確に再現される別のケースについて-今回はコードページの問題:
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
更新:これを実験することで、動作の別の特性を発見しました-プロファイラーは、RPC呼び出しでのそのパラメーターの入力値がであった場合にのみ、この誤った初期SETを使用しますNull。null以外の値が指定された場合(および.Net SqlClientのパラメーターの方向が「InputOutput」の場合)、その初期SETは、結果の出力値ではなく、真の入力値を保持します。ただし、入力がnullの場合は、代わりに出力値が設定されます。この観察結果は、これがプロファイラーRPCからTSQLへの表示変換におけるヌル処理のバグであるという概念をサポートしています。