VSDBCMD создает неверный файл обновления SQL

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

Мы используем аналогичный процесс в нашей сборке 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 аргументирует правильно, или прямая ошибка инструмента. На вашем месте я бы вручную поэкспериментировал с инструментом, чтобы убедиться, что из двух применимо.
Насколько мне известно, представленная выше процедура работает нормально, поэтому я склонен полагать, что с вашей реализацией что-то не так.

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

CREATE TABLE [dbo][TableName]

это было

CREATE TABLE [TableName]

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

CREATE TABLE [QAUser_SCHEMA].[TableName]

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

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

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