#sql-server #azure-devops
#sql-server #azure-devops
Вопрос:
Я пытаюсь развернуть обновления БД на SQL Server через Azure CI DACPAC, но я продолжаю получать сообщение об ошибке «может произойти потеря данных», что приводит к сбою развертывания.
Предупреждение SQL72015: столбец [dbo].[MyTable].[NonExistantField] удаляется, может произойти потеря данных.
Почему он пытается удалить столбец, который не существует? Я нигде не могу найти ссылку на это поле. Как мне заставить его прекратить попытки удалить столбец?
Во-вторых, и в более общем плане, есть ли где-нибудь параметр, при котором я могу принудительно развернуть его, даже если произойдет потеря данных? Меня не волнует потеря данных, это не имеет значения, и эта ошибка заставляет меня обновлять всю базу данных вручную.
Комментарии:
1. Извините, в сообщении об ошибке четко указано, что в таблице есть не только поле, но и данные. Это не ошибка DACPAC, это функция безопасности SSMS. Проверьте свои параметры. Теперь, почему он падает? Потому что DACPAC переводит базу данных В ОПРЕДЕЛЕННОЕ СОСТОЯНИЕ. В котором, похоже, нет поля, но оно есть в базе данных, отсюда и падение.
2. @TomTom Сообщение об ошибке неверно. Я смотрю на целевую базу данных. Поле не существует. Он никогда не существовал.
3. Вы уверены, что смотрите на правильную базу данных? Это было бы интересно. Давным-давно отказался от DACPAC из-за проблем, связанных с — ну — порядком вещей, так что — не специалист в текущей итерации.
4. @TomTom Совершенно уверен. На целевом сервере присутствует только одна база данных, поэтому двусмысленности нет.
5. Даже если вы не заботились о потере данных, развертывание все равно не будет выполнено, потому что удаление несуществующего столбца приведет к сбою, в результате чего остальная часть развертывания будет прервана — поэтому первым делом остается определить, откуда оно исходит. Это особенно верно, потому что, если развертывание не согласуется с вами в отношении структуры БД, неизвестно, какой еще хаос это может нанести, если вы просто скажете ему игнорировать и продолжить.
Ответ №1:
Это зависит от того, как вы пытаетесь развернуть свои обновления. Будет полезно просмотреть ваш шаг развертывания, чтобы получить некоторые рекомендации. В качестве примера, если вы развертываете через SqlPackage, вы можете использовать /p:BlockOnPossibleDataLoss='False' option .
Ответ №2:
Я не знаю, в чем была точная проблема, но решение состояло в том, чтобы войти в БД через SSMS, удалить таблицу-нарушитель, а затем разрешить ее воссоздание с помощью deployment.
Как ни странно, в моей первой попытке я удалил таблицу и воссоздал ее в SSMS, а затем выполнил развертывание, и оно все равно завершилось неудачей с предупреждением о потере данных.