В то время как этот вопрос основан на том, что данные не заботятся, иногда обслуживание данных имеет важное значение.
Если это так, я написал список шагов по восстановлению из кошмара Entity Framework, когда в базе данных уже есть таблицы с таким же именем: Как восстановить из кошмара Entity Framework - в базе уже есть таблицы с тем же именем
Видимо ... Модератор счел нужным удалить мой пост, поэтому я вставлю его сюда:
Как восстановить данные из кошмара Entity Framework - в базе данных уже есть таблицы с таким же именем
Описание : Если вы новичок в EF, и вы похожи на нас, вы окажетесь в состоянии, когда вы либо не сможете создать новую локальную базу данных, либо не сможете применить обновления к вашей производственной базе данных. Вы хотите вернуться к чистой среде EF и затем придерживаться основ, но вы не можете. Если вы работаете на производстве, вы не можете создать локальную базу данных, а если вы работаете на локальной, ваш производственный сервер не синхронизируется. И, наконец, вы не хотите удалять данные производственного сервера.
Симптом : не удается запустить Update-Database, поскольку он пытается запустить сценарий создания, а в базе данных уже есть таблицы с тем же именем.
Сообщение об ошибке: System.Data.SqlClient.SqlException (0x80131904): в базе данных уже есть объект с именем ''.
Предпосылки проблемы : EF понимает, где находится текущая база данных, по сравнению с тем, где находится код, основываясь на таблице в базе данных с именем dbo .__ MigrationHistory. Когда он смотрит на сценарии миграции, он пытается согласовать, где он был в последний раз, со сценариями. Если это невозможно, он просто пытается применить их по порядку. Это означает, что он возвращается к исходному сценарию создания, и если вы посмотрите на самую первую часть команды UP, это будет CreeateTable для таблицы, в которой произошла ошибка.
Чтобы понять это более подробно, я бы рекомендовал просмотреть оба видео, на которые есть ссылки здесь:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Решение : Нам нужно заставить EF думать, что текущая база данных обновлена, не применяя эти команды CreateTable. В то же время мы хотим, чтобы эти команды существовали, чтобы мы могли создавать новые локальные базы данных.
Шаг 1: Чистая производственная база данных
Сначала сделайте резервную копию вашей производственной базы данных. В SSMS щелкните правой кнопкой мыши базу данных, выберите «Задачи> Экспортировать приложение уровня данных ...» и следуйте инструкциям. Откройте производственную базу данных и удалите / удалите таблицу dbo .__ MigrationHistory.
Шаг 2. Чистая локальная среда.
Откройте папку с миграциями и удалите ее. Я предполагаю, что вы можете получить все это из мерзавца, если это необходимо.
Шаг 3: Воссоздать начальный.
В диспетчере пакетов запустите «Enable-Migrations» (EF предложит вам использовать -ContextTypeName, если у вас несколько контекстов). Запустите «Add-Migration Initial -verbose». Это создаст начальный скрипт для создания базы данных с нуля на основе текущего кода. Если у вас были какие-либо начальные операции в предыдущем файле Configuration.cs, скопируйте их.
Шаг 4: Трюк EF.
В этот момент, если мы запустим Update-Database , мы получим исходную ошибку. Итак, нам нужно обмануть EF, думая, что он актуален, без выполнения этих команд. Итак, перейдите к методу Up в начальной миграции, которую вы только что создали, и закомментируйте все это.
Шаг 5: Обновление базы данных
Если в процессе Up нет кода, который нужно выполнить, EF создаст таблицу dbo .__ MigrationHistory с правильной записью, чтобы сказать, что он правильно выполнил этот скрипт. Иди и проверь, если хочешь. Теперь раскомментируйте этот код и сохраните. Вы можете снова запустить Update-Database, если хотите убедиться, что EF считает, что она обновлена. Он не выполнит шаг Up со всеми командами CreateTable, потому что думает, что это уже сделано.
Шаг 6: Подтвердите, что EF действительно актуален
Если у вас был код, к которому еще не применены миграции, это то, что я сделал ...
Запустите «Add-Migration MissingMigrations». Это создаст практически пустой скрипт. Поскольку код уже был там, на самом деле были правильные команды для создания этих таблиц в начальном сценарии миграции, поэтому я просто вырезал CreateTable и эквивалентные команды удаления в методах Up и Down.
Теперь снова запустите Update-Database и посмотрите, как он выполняет ваш новый скрипт миграции, создавая соответствующие таблицы в базе данных.
Шаг 7: Подтвердите и подтвердите.
Сборка, тестирование, запуск. Убедитесь, что все работает, затем внесите изменения.
Шаг 8: Сообщите остальным членам вашей команды, как действовать.
Когда следующий человек обновится, EF не будет знать, что произошло, поскольку сценарии, которые он выполнял раньше, не существуют. Но, если предположить, что локальные базы данных могут быть снесены и созданы заново, это все хорошо. Им нужно будет удалить свою локальную базу данных и снова создать ее из EF. Если бы у них были локальные изменения и ожидающие миграции, я бы порекомендовал им снова создать свою БД на главном компьютере, переключиться на свою функциональную ветвь и заново создать эти сценарии миграции с нуля.
DROP DATABASEто ....