Ошибки публикации SSDT при создании предварительного просмотра публикации

Я использую Visual Studio 2013 для управления файлом .sqlproj, содержащим схему нашей базы данных. Схема была успешно развернута десятки раз.

При попытке публикации в одной конкретной целевой базе данных шаг «Создание предварительного просмотра публикации» кажется неудачным, но ошибка не выдается. Результат предварительного просмотра включает некоторые ожидаемые предупреждения:

  • Столбец {...} удаляется, возможна потеря данных.
  • Если это развертывание выполняется, изменения в {...} могут привести к ошибкам времени выполнения в {...}
  • Это развертывание может вызвать ошибки во время выполнения, потому что изменения в {...} заблокированы зависимостью {...} в целевой базе данных.

Я снял флажок «Блокировать инкрементное развертывание, если может произойти потеря данных».

Предварительный просмотр просто останавливается, а скрипт не создается.


sql-server-data-tools dacpac sqlcmd
person Eric Patrick    schedule 19.02.2015    source источник

Ответы (4)


arrow_upward
28
arrow_downward

Это происходит, когда в целевой базе данных существует хранимая процедура (или представление, ограничение или другой объект), которая не включена в ваш sqlproj, которая ссылается на таблицу, которая будет изменена путем развертывания вашего sqlproj. SSDT, по-видимому, не может определить, является ли изменение безопасным, если ссылающаяся вещь не включена в ваш sqlproj, а затем он ошибается в безопасности, блокируя развертывание.

Отключение параметра «Блокировать инкрементное развертывание при возможной потере данных» только ослабляет проверку на потерю данных. Параметр «Блокировать инкрементное развертывание при возникновении ошибок времени выполнения» отсутствует.

У вас есть три варианта:

  1. добавить любые хранимые процедуры, представления или что-то еще из целевой базы данных в ваш sqlproj

  2. снимите флажок «Проверить развертывание» в параметрах публикации ssdt (это опасно, если вы не знаете о других ссылающихся sprocs и не знаете, что они не сломаются)

  3. если вы уверены, что все, что должно существовать в целевой базе данных, содержится в вашем sqlproj, вы можете включить опцию «Перетаскивать объекты в цель, но не в источник»

person gordy    schedule 26.09.2015
comment
4. Вручную добавьте / удалите объект из базы данных, чтобы dacpac не обнаружил различий. Я предполагаю, что такие действия, как удаление столбца, скорее разовые. - person Raf; 22.05.2020
comment
Это правильно. Я также предлагаю сравнить схему, чтобы найти разницу между исходной и целевой базами данных. Для меня это была статистика, которая автоматически создавалась в базе данных. Отказ от них сработал для меня! - person Shreyak; 28.05.2020
comment
У меня было это с привязкой к схеме. Пришлось написать логику для перечисления всех связанных со схемой представлений, сохранения их сценариев, удаления их, выполнения автоматического развертывания SSDT и последующего воссоздания ранее удаленных представлений. - person Cee McSharpface; 12.08.2020
comment
Еще одно: проверьте, что один из ваших скриптов случайно не помечен как не в сборке. У меня было, если это развертывание выполняется безымянным, будет отброшено и не будет повторно создано исключение из-за этого. - person Juozas; 27.09.2020

arrow_upward
1
arrow_downward

Проблема также может быть вызвана добавлением к объекту базы данных неправильной схемы. Например, таблица, на которую имеется ссылка в операторе SQL хранимой процедуры, и таблица, к которой добавляется неправильное имя схемы.

Кроме того, у нас были некоторые разрешения для конкретной группы безопасности, которые после удаления решения собирались заново. Для устранения ошибки выполните сравнение схемы кода проекта и целевой базы данных. Удаляйте различия из базы данных, пока не заработает функция публикации. Последний элемент, который вы удалили из базы данных, - ваш виновник.

person Frank    schedule 28.02.2019

arrow_upward
0
arrow_downward

Последнее предупреждение выглядит не просто предупреждением:

В этом развертывании могут возникать ошибки во время выполнения, поскольку изменения в {...} блокируются зависимостью {...} в целевой базе данных.

похоже, был виновником остановки оставшейся части предварительного просмотра и генерации скрипта.

Интересно, что внесенное изменение схемы не нарушило бы триггеры, указанные в выходных данных предварительного просмотра.

person Eric Patrick    schedule 19.02.2015

arrow_upward
0
arrow_downward

удаление привязки схемы из представления позволяет успешной публикации только с предупреждениями

person bshah    schedule 07.07.2021