T-SQL コードベースの変更管理に DBDeploy.NET を使用しています。DBDeploy は、開発者が変更スクリプトの番号付きセットを維持することによって機能します。デプロイが (NAnt 経由で) トリガーされると、DBDeploy は変更ログ テーブルを調べて、インスタンスを最新の状態にするために実行する必要があるパッチを判断します。
私が抱えている問題は、インデックス付きビューを作成するために必要な設定を行うことです。QUOTED_IDENTIFIER、ANSI_NULLS、および ARITHABORT はすべてオンにする必要があります。はい、インデックス付きビューを作成/変更する変更スクリプトの先頭に、これらの SET ステートメントを簡単に配置できます。ただし、これらの設定は接続レベルです。後で新しいインスタンスをゼロから構築する場合はどうなりますか? 新しいインスタンスで DBDeploy を実行すると、すべての変更スクリプトが単一の接続で実行される最終的な SQL スクリプトに効果的に連結されるため、これらの設定は後続のすべての変更スクリプトに影響を与えます。さらに悪いのは、QUOTED_IDENTIFIER のような解析時オプションです。これは、以前のすべての変更スクリプトにも適用されます。そう：
- SQL Server 2000 を使用しています。接続レベルの設定の解釈は正しいですか? つまり、GO を使用してスクリプトをバッチに分割しても、これらの SET オプションの範囲は制限されません。接続レベルの設定がバッチレベルの名前に変更された後のバージョンはどうですか?
- SETを解除する方法はありますか? 私が理解しているように、接続レベルの設定は 3 値です。つまり、ON、OFF、およびデフォルトです。デフォルトは、SQL ステートメントの内容、インスタンス設定、データベース設定、および永続化されたユーザー設定に基づいて解釈されます。何かを ON に設定すると、それを OFF に設定するだけで元に戻すことはできません。これは、それが以前の設定であった場合、デフォルトがマスクされるためです。
- 設定する前に接続レベルの設定の状態を保存して、後で手動で復元できるようにする方法はありますか?
代替手段は最悪です：
- SS2K では 4000/8000 文字の制限があるため、インデックス付きビューの各 create/alter ステートメントを動的 SQL でラップできます。これにより、SET ステートメントの範囲がかなり制限されます。
- プロジェクト レベルで使用される SET オプションを修正し、すべての開発者にそれらの SET オプションを各変更スクリプトの先頭に配置して強制するように要求するポリシーを制定できます。適用されます。
- 変更スクリプトごとに常に新しい接続を使用するように DBDeploy 自体にパッチを適用できますが、変更スクリプトの取り消しを処理する方法を再設計する必要があります。
では、何ができるでしょうか。