SQL Server 2000 - Как восстановить предыдущее состояние настроек уровня соединения

Question

Я использую DBDeploy.NET для управления управлением изменениями в своей кодовой базе T-SQL. DBDeploy работает разработчиком, поддерживающим нумерованный набор сценариев изменений. Когда развертывание запускается (через NAnt), DBDeploy просматривает таблицу изменений и определяет, какие исправления необходимо выполнить, чтобы обновить экземпляр.

Проблема с настройкой необходимых параметров, необходимых для создания индексированного представления. QUOTED_IDENTIFIER, ANSI_NULLS и ARITHABORT все должно быть включено. Да, я могу легко поместить эти инструкции SET в начало скрипта изменений, который создает/изменяет индексированное представление. Но эти настройки - это уровень соединения. Что, если позже я создаю новый экземпляр с нуля? Когда я запускаю DBDeploy в новом экземпляре, эти параметры будут пропускать все последующие сценарии изменений, так как все скрипты смены эффективно объединены в окончательный сценарий SQL, который будет выполняться в одном соединении. Хуже используются параметры синтаксического анализа типа QUOTED_IDENTIFIER, которые также будут применяться ко всем сценариям изменений. Итак:

1. Я нахожусь на SQL Server 2000. Является ли моя интерпретация настроек уровня подключения правильной? То есть использование GO для разрыва скрипта в партии не делает ничего, чтобы ограничить объем этих опций SET. Как насчет более поздних версий, где параметры уровня соединения были переименованы в пакетном режиме?
2. Есть ли способ распаковать SET? Насколько я понимаю, настройки уровня соединения триачны - то есть ON, OFF и по умолчанию, где по умолчанию интерпретируется на основе содержимого инструкции SQL, настроек экземпляра, настроек базы данных и постоянных пользовательских настроек. Если я устанавливаю что-то в положение ВКЛ, я не могу его отменить, просто отменив его, установив его в положение ВЫКЛ, потому что он будет маскировать значение по умолчанию, если это было раньше.
3. Есть ли способ сохранить состояние настройки уровня соединения перед его настройкой, поэтому я могу вручную восстановить его после?

альтернативы сосать:

1. можно обернуть каждый создать/альтер заявление для индексированных представлений в динамическом SQL - с его 4000/8000 голец ограничение на SS2K. Это очень хорошо ограничило бы объем инструкций SET.
2. Я могу установить политику фиксации опций SET, которые будут использоваться на уровне проекта, и потребовать, чтобы все разработчики разместили эти параметры SET в верхней части каждого сценария изменения, чтобы обеспечить его соблюдение, поскольку пока не указывается время развертывания, сценарии изменения будут применены.
3. Я могу исправить DBDeploy, чтобы всегда использовать новое соединение для каждого скрипта смены, но это потребует перепроектирования способа обработки дескрипторов изменений.

Итак, что можно сделать, и что мне делать?

Answer 1

К сожалению, я не верю, что есть способ установить текущий статус SET в вашем соединении.

Я не использую DBDeploy.NET, но это звучит явно как ограничение с помощью инструмента. DBDeploy.NET должен определять внутри метаданных проекта (например, в проектах Visual Studio DB) то, что должны быть по умолчанию для предикатов SET для любой базы данных, которую он впоследствии развертывает.

Чтобы избежать «кровотечения» между сценариями, он должен автоматически добавлять инструкции SET, используя эти значения по умолчанию на уровне проекта, до того, как каждый скрипт объединяется в финальный скрипт.

Наличие такого детерминированного подхода означает, что разработчики могут понять, в каком состоянии будет находиться каждый из этих SET, когда их сценарий будет выполнен. В противном случае скрипты будут подчиняться прихотям различных значений по умолчанию, которые присутствуют в экземпляре клиента SQL или экземпляре сервера.