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. Есть ли способ отменить установку? Насколько я понимаю, настройки на уровне соединения являются тройными - то есть ON, OFF и default, где default интерпретируется на основе содержимого оператора SQL, настроек экземпляра, настроек базы данных и постоянных пользовательских настроек. Если я установил что-либо на ON, я не смогу отменить это, просто отменив это, установив это на OFF, потому что это маскирует значение по умолчанию, если это было то, что было раньше.
3. Есть ли способ сохранить состояние настройки уровня соединения перед ее настройкой, чтобы я мог восстановить ее вручную?

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

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

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

Answer 1

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

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

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

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