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

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

2 голосов
/ 30 июня 2010

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

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

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

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

1 Ответ

0 голосов
/ 08 августа 2011

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

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

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

...