それを行う良い方法はありません。これは、ストアド プロシージャの制限です。オプションは次のとおりです:
<オール> <リ>手順を ユーザー定義関数 に切り替えます .今日、世界中で、人々は関数であるべきストアド プロシージャを作成しています。教育の問題です。あなたの状況は、その理由の良い例です。プロシージャが代わりに UDF である場合は、直感的にできるはずだと思うとおりに、次のことを実行できます。
SELECT * FROM udf_who2()
WHERE login='bmccormack'
手順にどうしても触れられず、しなければならない場合 これをSQLで行うと、ファンキーになる必要があります。別のストアド プロシージャを作成して、元のプロシージャをラップします。新しいプロシージャ内で既存のプロシージャを呼び出し、値を一時テーブルに入れ、必要なフィルターを使用してそのテーブルに対してクエリを実行し、その結果を外部に返します。
SQL Server 2005 以降、ユーザー定義関数はデータ取得をカプセル化する方法です。ストアド プロシージャは、ビューと共に、特定の状況で使用する特殊なツールです。どちらも適切なタイミングで非常に便利ですが、最初の選択肢ではありません.上記の例 (A) は関数のすべての結果を取得し、(B) サブクエリのようにその結果セットをフィルタリングすると考える人もいるかもしれません。 そうではない . SQL Server 2005+ はそのクエリを最適化します。 login にインデックスがある場合 、クエリ実行プランにテーブル スキャンが表示されません。非常に効率的です。
編集 :UDF の内部は SP の内部と似ていることを付け加えておきます。 ロジックに問題がある場合 回避したいSPの場合でも、関数に変更できます。私は何度か、理解する必要のない大きくて恐ろしい手続きコードを取り上げ、それを関数にうまく変換しました。唯一の問題は、手順が変更された場合です。 結果を返すことに加えて何か; UDF はデータベース内のデータを変更できません。