2016-10-12 1 views
0

У меня есть база данных, импортированная в .sqlproj, и профиль публикации .publish.xml, который публикует изменения в удаленной БД.SSDT publish script обновляет процедуры без изменений

Полагаю, что когда я нажимаю правой кнопкой мыши -> Публиковать -> Сгенерировать скрипт, он должен рассчитать разницу между локальными определениями и удаленной БД и сгенерировать сценарий, чтобы привести удаленный БД в соответствие.

Все это, кажется, работает хорошо, однако, сценарий он генерирует всегда содержит ALTER FUNCTION и ALTER PROCEDURE заявления для одних и тех же 40 или около процедур и функций (из в общей сложности около 1000 определена), ли они изменились или нет. Когда я сравниваю операторы ALTER со скриптовой функцией как -> ALTER с скриптом в SSMS, они точно такие же.

Итак, мой вопрос: почему VS думает, что это разные, или почему они воссоздают их в любом случае, если они одинаковы?

Примечание:

  • функция не является специальным - некоторые из них так просто, как определяющий VARCHAR, установив его значение и возвращает его.
  • Я попытался запустить сценарии ALTER в базе данных, но они по-прежнему генерируются.
  • Я проверил свойства (щелкните правой кнопкой мыши -> свойства) в SSMS, но не вижу ничего очевидного в том, что он всегда воссоздает, а тем, что он не делает.
  • Мой опубликованный профиль - это стандартное болото.

Благодаря

+2

Может вы используете «сравнение схемы» в SSDT, чтобы узнать, что он «думает» о различиях? Часто бывает полезно сделать это, а затем вставить «целевой» скрипт в исходный файл; таким образом, вы можете быть уверены, что у вас есть «каноническая» форма скрипта.Я вижу это чаще с ограничениями и триггером, чем с хранимыми процедурами, чтобы быть справедливым. Может помочь поисковая система «Каноническая форма SSDT». –

ответ

0

Update:

переименованием .dacpac как .zip и извлекая model.xml я мог видеть <HeaderContents> некоторых процедур имели &#xA; (LF - Line Feed).

Это заставило меня понять, что по некоторым причинам все мои .SQL-файлы имели окончание строк Unix (LF), а не окончания строк Windows (CR LF). Преобразование всех файлов в конец оконной строки (using notepad++) решило проблему.

Оригинал:

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

SET @doesnt_work = 
'FOO 
BAR' 

можно заменить

SET @works = 'FOO' + CHAR(13) + CHAR(10) + 'BAR' 

Примечание: Это больше, чем обходной путь решения, и, надеюсь, кто-то может предложить лучший способ сделать это ...

+1

Если я создать базу данных, содержащую _только_ процедуры '' '' [spReturnsEmbeddedCR] А.С. \t DECLARE @mystring VARCHAR (100) CREATE ПРОЦЕДУРА [DBO]. \t Set @mystring = 'Некоторые \t \t \t \t \t Текст'; \t SELECT @mystring; RETURN 0 '' '' он не перераспределяется. Возникают ли какие-то проки? Сравнение схемы довольно чувствительно к кажущимся безвредным изменениям. –

+0

Вы правы, есть что-то более активное. Теперь я пытаюсь использовать sqlpackage для развертывания изменений, и, похоже, это зависит от того, развертывается ли я с локального компьютера или сервера TFS. Оба являются машинами для Windows - любая идея, почему они будут обрабатывать новые строки по-разному? – Taran

Смежные вопросы