関数/ストアドプロシージャの作成時のスキーマチェックの無効化

SQL Server 2008 R2データベースへの変更を実行するプロセスを自動化しようとしています。配置したプロセスは、ストアドプロシージャと関数を削除して再作成し、スクリプトを実行してテーブル/列/データを変更します。残念ながら、スクリプトの1つでは、最初に機能の1つを配置する必要があります。しかし、最初にテーブル/列/データ変更スクリプトから追加される列に依存するため、最初にすべてのストアドプロシージャ/関数の変更を実行することはできません。

SQL Serverが関数/ SPの定義で使用される列を検証せずにストアドプロシージャと関数を実行できるかどうか疑問に思っていましたか？探してみましたが、これを有効にする条件またはコマンドが見つかりませんでした。

まだ存在しないオブジェクト（テーブルや関数など）を参照するストアドプロシージャを作成できます。既に存在するオブジェクトにまだ存在しない列を参照するストアドプロシージャを作成することはできません。これは、名前解決の遅延の両刃の剣です。SQLServerには、すべてではない場合もありますが、疑問の恩恵があります。Erlandのアイデアを参照してSET STRICT_CHECKS ON;、これが機能する場所とそれが壊れる場所のアイデアを入手してください。

http://www.sommarskog.se/strict_checks.html

（そして、彼はあなたが望んでいるものの正反対をどのように望んでいますか-あなたは存在に関係なく何でもコンパイルできるようにしたい、そして彼はすべての単一の列またはテーブルがチェックされることを望んでいます）

次のような設定はありませんSET DEFERRED_NAME_RESOLUTION OFF;：

http://connect.microsoft.com/sql/127152

そして、のような設定はありませんIGNORE ALL_RESOLUTION;。

次のようないくつかの方法でこれを回避できます。

（a）影響を受けるストアドプロシージャで動的SQLを使用します。

（b）CREATE PROCEDURE何も含まないスタブを構築し、残りのスクリプトを実行ALTER PROCEDUREしてから、実際の本体を持つを実行します（本質的に、2段階でプロシージャを展開します）。

（c）操作の順序について、展開ツールをよりスマートにします。テーブルの変更に関数の存在が必要な場合は、それらの変更を最後にスクリプト化します。RedGateのSQL Compareなどのスキーマ比較ツールは、適切な依存関係の順序でスクリプトを生成するのに適しています。使用しているツールについては言及しませんが、これを行っていない場合は...

（d）Martin Smithにはここで興味深い回避策がありますが、私はそれを試していません。

最初に問題のオブジェクトを削除または名前変更してから、元のストアドプロシージャを動的SQLとして実行するストアドプロシージャを作成できます。これにより、動的SQLを使用するために実際のストアドプロシージャを書き換える必要がなくなります。

以下のコードは、まだ存在しない列を参照するストアドプロシージャを実行します（Expense_Super_Compare）

IF OBJECT_ID('Expense_Super_Compare_Results', 'U') IS NOT NULL
BEGIN
     EXEC('DROP TABLE Expense_Super_Compare_Results');
END

exec('exec dbo.Expense_Super_Compare');