После установки пользовательского объекта CLR Инструменты разработчика Sql Server (SSDT) VS2012 не разрешают обновление. Ошибка: «Обнаружен дрейф исходной схемы. Нажмите «Сравнить», чтобы обновить. После обновления происходит то же самое.
Пробовал В настройках я установил объект только как хранимые процедуры. Настройки -> Общие -> Блокировать возможную потерю данных -> пробовал и вкл и выкл.
Такой цикл также может быть вызван сбоем сборки упомянутого проекта SSDT. Упомянутый проект может отсутствовать, быть выгруженным или иметь ошибку, препятствующую завершению сравнения.
Это не ответ, а ключ к решению этой проблемы.
Я должен был обновить столбец с varchar[200] на varchar[MAX] и тоже столкнулся с этой проблемой. Итак, я зашел на сервер и попытался обновить базу данных вручную через SQL Management Studio, которая была там установлена, и я получил эту ошибку:
"Saving changes is not permitted. The changes you have made require the folloing tables to be drpped and re-created. You have either made changes to a table that can't be re-created or enable the option Prevent saving changes that require the table to be re-created."
Кажется, что повторное создание таблицы настолько опасно, что «блокировать/разблокировать при возможной потере данных» не может справиться. Поэтому я думаю, что только если мы сможем обойти это ЛОКАЛЬНОЕ предупреждение, мы сможем обновить базу данных УДАЛЕННО.
Но почему от [200] до [max] приводит к повторному созданию таблицы? Это не имеет никакого смысла. Я пробовал от [200] до [1000], и это тоже не сработало. Это может быть ключом к этой проблеме.
И если вы сделаете то же самое обновление в проводнике сервера в VS, а не в SQL Management Studio, оно сработает. Опять же, почему?
Это может произойти, когда пользователь БД "меняется".
На следующей довольно пугающей странице форума рассказывается о проблемах, когда иностранные хакеры пытались взломать доступ к пользователю «sa» db, при каждой попытке меняя отметку даты и времени пользователя sa (что рассматривается как дрейф схемы):
Здесь также упоминается, что вы можете несколько раз запросить пользователя sa, чтобы узнать, происходит ли это с вами:
SELECT * FROM sys.server_principals WHERE principal_id=1
В настоящее время я испытываю ту же проблему (что пользователь sa-user изменяется; я еще ничего не знаю о хакерах), и мне еще предстоит найти решение.
Изменить. Я включил ведение журнала в брандмауэре Windows через properties > logging, и мы установили правило блокировки для порта 3071, через который проходил много необъяснимого трафика. Потом проблема ушла.
Пробовал запускать VS от имени администратора, все работает.
