SQL72007: Ошибка проверки синтаксиса: «Произошел неожиданный конец файла». в партии рядом:

В проекте SSDT (с использованием VS2017 / VS2015, SSDT версии 15.1.61702.140) я не могу создать свой проект. Компилятор продолжает жаловаться на оператор sql в моем PostDeploymentScript (да, я установил для свойства BuildAction значение PostDeploy). Заявление sql:

if ('$(env)' = 'dvp')    
BEGIN
    PRINT 'creating users for dvp'
    :r .\SecurityAdditions\usersdvp.sql 
END
ELSE IF ('$(env)' = 'qat')
BEGIN
    PRINT 'creating users for qat'
    :r .\SecurityAdditions\usersqat.sql
END 

Фактическое сообщение об ошибке:

D:\My\File\Path\PostDeploymentScript.sql (lineNum, col): Error: SQL72007:
The syntax check failed 'Unexpected end of file occurred.' in the batch near:

Номер строки, указанный в сообщении об ошибке, в последней строке (конце). Есть идеи, что вызывает это?


person anish    schedule 11.05.2017    source источник


Ответы (4)


Очевидно, проблема была связана с GO операторами, которые были у меня в файлах, на которые я ссылался. Наличие GO операторов внутри блока if else недопустимо. Здесь есть статья, объясняющая это. Мне удалось заставить его работать, удалив все операторы GO из файлов, на которые есть ссылки, и разделив if else на два if.

IF ('$(env)' = 'dvp')
BEGIN 
    :R .\SecurityAdditions\UsersDVP.sql
END

IF ('$(env)' = 'qat')
BEGIN
    :R .\SecurityAdditions\UsersQAT.sql
END
GO 
person anish    schedule 12.05.2017
comment
Не работает, если у вас есть GO внутри скрипта UsersDVP.sql. - person Vinicius Gonçalves; 21.03.2018

У меня была такая же ошибка, потому что я забыл завершить один из сценариев, включенных в сценарий после развертывания, с помощью оператора GO. Что затрудняет исправление, так это то, что ошибка будет указывать на первую строку в следующем сценарии, а не на сценарий, в котором отсутствует инструкция GO.

person Dean    schedule 07.02.2018

Я столкнулся с этой проблемой, когда пытался создать пользователей базы данных в проекте базы данных SQL. Установка действия сборки на None бесполезна, потому что тогда ваш скрипт не запускается во время развертывания.

Я использовал такой скрипт для создания пользователей:

IF NOT EXISTS (SELECT * FROM sys.sysusers WHERE name='$(DbUserName)')
    BEGIN
        CREATE USER [$(DbUserName)] WITH PASSWORD = '$(DbPassword)';
        ALTER ROLE [db_owner] ADD MEMBER [$(DbUserName)];
    END

У меня было две переменные SQLCMD в файле проекта, и установка значения по умолчанию для одной из них фактически решила проблему. Это действительно странно, но я надеюсь, что однажды это поможет какой-нибудь бедной душе :)

person Ufuk Hacıoğulları    schedule 27.07.2018

Здесь я хочу поделиться своим опытом.

У меня такая же ошибка при создании моего проекта sql, но сценарий был другим и сложным.

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

  1. начал с условия IF, чтобы убедиться, что он выполняется только один раз для данной базы данных. Обратите внимание, что это не позволяет использовать инструкцию GO.
  2. затем Создать функцию, чтобы создать временную функцию. Ему нужен оператор GO перед созданием функции, главным образом потому, что он вносит изменения в схему базы данных. Это было сложно, потому что IF не допускает оператора GO.
  3. затем Обновите запрос, используя временную функцию, чтобы выполнить мое требование. Это нормально без инструкции GO
  4. затем DROP FUNCTION, чтобы удалить временную функцию. Это также изменение схемы базы данных, и в идеале требуется инструкция GO.

Чтобы справиться с этой ситуацией без оператора GO

  1. Я создал переменную, скажем, «@CreateFuntion NAVARCHAR (MAX)», и установил ее с помощью всего оператора Create Function.
  2. Выполнена функция создания с использованием EXEC sp_executesql @CreateFunction. Это запускает функцию Create в отдельном пакете. Я ожидал, что функция Drop потребует такой же обработки, но в моем случае она работала без GO, и EXEC sp_executesql может быть потому, что это был последний оператор в сценарии и в любом случае будет запущен в следующем пакете.
  3. Все остальное как есть
person rikencpatel    schedule 30.04.2021