База данных Visual Studio SQL Server не выполняется успешно из-за отсутствия столбца, который, кажется, присутствует

Question

В какой-то момент несколько лет назад я настроил проект в Visual Studio для вывода в базу данных Azure SQL V12 и попытался использовать sqlcmd со сценариями миграции (я также говорю, что в какой-то момент всеработать, и все, что обсуждалось ниже, превратило его в рабочий).

Мой сценарий после развертывания выглядит примерно так:

PRINT N'Starting post deployment';
:setvar WorkDirectory "F:\path\to\scripts"
PRINT N'Starting 1.01';
:r $(WorkDirectory)\1.01\Deployment.sql
PRINT N'Starting 1.02';
:r $(WorkDirectory)\1.02\Deployment.sql
PRINT N'Starting 1.03'; :r $(WorkDirectory)\1.03\Deployment103.sql
PRINT N'Starting 1.04'; :r $(WorkDirectory)\1.04\Deployment104.sql

После того, как я не внес никаких изменений в проект (в любом случае сознательно), яобнаружил, что когда я пытаюсь отладить / сгенерировать базу данных и применить сценарии миграции, я получаю сообщение об ошибке, потому что на столбец ссылаются, которого нет в таблице. Ниже приведен фрагмент сообщения из файла Deployment104.sql:

IF NOT EXISTS (SELECT *
               FROM sys.columns 
               WHERE Name = N'MissingColumn'
                 AND Object_ID = Object_ID(N'TableA'))
BEGIN
    ALTER TABLE TableA 
        ADD MissingColumn INT NOT NULL
END
GO

IF NOT EXISTS (SELECT 1 
               FROM information_schema.Routines
               WHERE ROUTINE_NAME = 'LIST_CODES'
                 AND ROUTINE_TYPE = 'PROCEDURE' 
                 AND ROUTINE_SCHEMA = 'dbo' )
BEGIN;
    EXEC('CREATE PROCEDURE dbo.LIST_CODES as set nocount on;')
END
GO

ALTER PROCEDURE [dbo].LIST_CODES 
AS
    SELECT * 
    FROM CodesTable ct 
    LEFT JOIN TableA ta ON ct.CodeId = ta.CodeId
    WHERE ta.MissingColumn= 1999
    ORDER BY ct.CodeId
GO

. БД в этом месте частично создается. Однако, когда я запускаю эту первую проверку, существует ли столбец, я фактически получаю запись назад, подразумевая, что столбец действительно существует в TableA. И все же я не вижу его в обозревателе сервера (VS 2019 Предварительный просмотр 16.4), и, очевидно, следующая часть скрипта не видит его тоже.

Что я делаю неправильно, и / или как можноЯ делаю сценарий и БД согласны с тем, какие столбцы существуют, а какие нет?

РЕДАКТИРОВАТЬ: как обновление, при запуске PostDeploymentScript происходит сбой, запуск самого проблемного сценария (в данном случае Deployment104) работает просто отличнопосле чего столбец и хранимая процедура отображаются в обозревателе серверов точно так, как ожидается, и на них могут ссылаться другие запросы.

Answer 1

Я считаю, что проблема в том, что вы пытаетесь добавить ненулевой столбец в существующую таблицу. Вам нужно будет добавить значение по умолчанию, например, 0 или использовать тип данных, который поддерживает ноль. Например:

BEGIN
    alter table TableA 
    ADD MissingColumn int NOT NULL DEFAULT 0
END

После второго НАЧАЛА также ставится точка с запятой.

Ток:

IF NOT EXISTS ( SELECT  1 FROM information_schema.Routines
   WHERE ROUTINE_NAME = 'LIST_CODES'AND ROUTINE_TYPE = 'PROCEDURE' AND ROUTINE_SCHEMA = 'dbo' )
BEGIN;
    EXEC('CREATE PROCEDURE dbo.LIST_CODES as set nocount on;')
END
GO

Исправлено:

IF NOT EXISTS ( SELECT  1 FROM information_schema.Routines
   WHERE ROUTINE_NAME = 'LIST_CODES'AND ROUTINE_TYPE = 'PROCEDURE' AND ROUTINE_SCHEMA = 'dbo' )
BEGIN
    EXEC('CREATE PROCEDURE dbo.LIST_CODES as set nocount on;')
END
GO

После этих изменений я смог заставить оператор работать в sqlfiddle. Вот ссылка http://sqlfiddle.com/#!18/51253/3

Answer 2

В итоге ответом стало разделение команды на собственный пакет, к сожалению, его нельзя обнаружить с помощью опубликованного кода. Последней инструкцией в Deployment103.sql была ALTER PROCEDURE, которая должна появиться сама по себе в пакете, но завершающий символ GO отсутствовал.

Похоже, t-sql не будет жаловаться на это(потому что в файле это выглядит так, будто оно в пакете). Это привело к тому, что следующие инструкции не работали корректно, пока первый оператор GO в Deployment104.sql.

Добавление следующих GO не решило проблемы (как и завершение Deployment103.sql с GO)

PRINT N'Starting 1.03'; :r $(WorkDirectory)\1.03\Deployment103.sql
PRINT N'Starting 1.04'; 
GO
:r $(WorkDirectory)\1.04\Deployment104.sql