VSDBCMD генерирует неверный файл обновления SQL

Question

У нас есть автоматизированный процесс сборки через TFS, проекты баз данных TFS и vsdbcmd. При развертывании проекта базы данных на нашем сервере базы данных сгенерированный сценарий SQL пытается "ИЗМЕНИТЬ" определенные хранимые процедуры, даже если эти хранимые процедуры еще не существуют в целевой базе данных. Вместо этого сценарий SQL должен содержать операторы CREATE для этих хранимых процедур. Это, очевидно, приводит к сбою развертывания базы данных, поскольку нет способа "изменить" хранимую процедуру, которая не существует.

У кого-нибудь есть идеи о том, что может быть причиной этого или как это можно исправить?

Answer 1

Выяснили, что было не так: в TFS определение таблицы не имело префикса схемы. Так что вместо (например)

CREATE TABLE [dbo][TableName]

это было

CREATE TABLE [TableName]

Отсутствие указанной схемы означало, что когда QA запускал vsdbcmd, схема, назначенная таблице, была схемой по умолчанию для отдельного работающего vsdbcmd. То, что на самом деле было создано, было эффективно, как если бы мы указали:

CREATE TABLE [QAUser_SCHEMA].[TableName]

Это вызвало vsdbcmd, когда позже запускаемый другим человеком, чья схема по умолчанию была [dbo], получил ошибку, которую мы видели, в основном генерируя инструкцию ALTER, потому что хранимая процедура уже была создана, хотя и в другой схеме.

Можно было бы подумать, что даже если изначально была указана неверная схема, однажды для процедуры была задана схема [dbo], что это будет считаться "другой" процедурой, однако это не так. Удаление оригинальной версии процедуры (с [QAUser_SCHEMA]) и повторный запуск vsdbcmd решили проблему.

TLDR; Всегда ставьте префикс объектов базы данных в ваших проектах базы данных с именем схемы.

Answer 2

Вы используете VSDBCMD для развертывания в целевой базе данных? VSDBCMD должен принимать в качестве входных данных файл.dbschema и строку подключения, и он генерирует соответствующий файл SQL. Если вы сгенерировали файл SQL, указав на другую БД, он не будет работать на сервере БД, который находится в другом состоянии.

Answer 3

Мы используем аналогичный процесс в нашей сборке TFS, я уверен, что он успешно обрабатывает вновь вставленные элементы (таблицы, столбцы, SP, индексы и т. Д.).

Сначала мы генерируем.dbschema старой БД, вызывая VSDBCMD с:

/a:import /dsp:sql /model:C:\PATH\old.dbschema /cs:"Server=SQLSERVER;Integrated Security=False;Pooling=False;Initial Catalog=OLDDB;User=username;Password=password;

Затем мы генерируем.dbschema самого нового состояния БД, которое на более раннем этапе было развернуто (через MSBuild):

/a:import /dsp:sql /model:C:\PATH\new.dbschema /cs:"Server=SQLSERVER;Integrated Security=False;Pooling=False;Initial Catalog=NEWDB;User=username;Password=password;

Наконец, мы в третий раз вызываем VSDBCMD, чтобы он генерировал ALTER:

/a:deploy /dsp:sql /model:C:\PATH\new.dbschema /targetmodelfile:C:\PATH\old.dbschema /DeploymentScriptFile:C:\PATH\DB_Alter.sql /p:Targetdatabase="DB" 

Этот сгенерированный DB_Alter.sql может быть применен к производственному SQL, на котором выполняется предыдущее состояние БД, чтобы преобразовать его в последний.

То, что вы намекаете, может быть связано либо с неправильным формированием аргументов VSDBCMD, либо с прямой ошибкой инструмента. На вашем месте я бы вручную поэкспериментировал с инструментом, чтобы убедиться, какое из двух применимо.
Насколько мне известно, представленная выше процедура работает нормально, поэтому я склонен полагать, что с вашей реализацией что-то не так.