Chociaż podstawą tego pytania jest brak dbałości o dane, czasami utrzymanie danych jest niezbędne.
Jeśli tak, napisałem listę kroków, jak odzyskać z koszmaru Entity Framework, gdy baza danych ma już tabele o tej samej nazwie tutaj: Jak odzyskać z koszmaru Entity Framework - baza danych ma już tabele o tej samej nazwie
Najwyraźniej ... moderator uznał za stosowne usunąć mój post, więc wkleię go tutaj:
Jak odzyskać od koszmaru Entity Framework - baza danych ma już tabele o tej samej nazwie
Opis : Jeśli jesteś podobny do nas, gdy Twój zespół jest nowy w EF, skończysz w stanie, w którym albo nie możesz utworzyć nowej lokalnej bazy danych, albo nie możesz zastosować aktualizacji do swojej produkcyjnej bazy danych. Chcesz wrócić do czystego środowiska EF, a następnie trzymać się podstaw, ale nie możesz. Jeśli sprawisz, że będzie działać w środowisku produkcyjnym, nie możesz utworzyć lokalnej bazy danych, a jeśli zaczniesz działać lokalnie, serwer produkcyjny nie będzie zsynchronizowany. I wreszcie, nie chcesz usuwać żadnych danych serwera produkcyjnego.
Objaw : nie można uruchomić Update-Database, ponieważ próbuje uruchomić skrypt tworzenia, a baza danych zawiera już tabele o tej samej nazwie.
Komunikat o błędzie: System.Data.SqlClient.SqlException (0x80131904): W bazie danych istnieje już obiekt o nazwie „”.
Tło problemu : EF rozumie, gdzie znajduje się bieżąca baza danych w porównaniu z miejscem, w którym znajduje się kod, na podstawie tabeli w bazie danych o nazwie dbo .__ MigrationHistory. Kiedy patrzy na skrypty migracji, próbuje ponownie porównać ze skryptami, gdzie było ostatnio. Jeśli nie może, po prostu próbuje zastosować je po kolei. Oznacza to, że wraca do początkowego skryptu tworzenia i jeśli spojrzysz na pierwszą część polecenia UP, będzie to CreeateTable dla tabeli, w której wystąpił błąd.
Aby lepiej to zrozumieć, polecam obejrzenie obu filmów wymienionych tutaj:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Rozwiązanie : Musimy nakłonić EF do myślenia, że bieżąca baza danych jest aktualna, ale nie stosujemy tych poleceń CreateTable. Jednocześnie nadal chcemy, aby te polecenia istniały, abyśmy mogli tworzyć nowe lokalne bazy danych.
Krok 1: Oczyszczanie produkcyjnej bazy danych
Najpierw wykonaj kopię zapasową produkcyjnej bazy danych. W programie SSMS kliknij prawym przyciskiem myszy bazę danych, wybierz „Zadania> Eksportuj aplikację warstwy danych ...” i postępuj zgodnie z wyświetlanymi instrukcjami. Otwórz produkcyjną bazę danych i usuń / upuść tabelę dbo .__ MigrationHistory.
Krok 2: Czyszczenie środowiska lokalnego
Otwórz folder migracji i usuń go. Zakładam, że w razie potrzeby możesz odzyskać to wszystko z gita.
Krok 3:
Ponownie utwórz początkowe W Menedżerze pakietów uruchom „Enable-Migrations” (EF wyświetli monit o użycie -ContextTypeName, jeśli masz wiele kontekstów). Uruchom „Add-Migration Initial -verbose”. Spowoduje to utworzenie początkowego skryptu do utworzenia bazy danych od podstaw na podstawie bieżącego kodu. Jeśli w poprzednim pliku Configuration.cs były jakieś operacje inicjujące, skopiuj je.
Krok 4: Trick EF
W tym momencie, gdybyśmy uruchomili Update-Database , otrzymalibyśmy oryginalny błąd. Musimy więc oszukać EF, aby pomyślał, że jest aktualny, bez uruchamiania tych poleceń. Więc przejdź do metody Up w utworzonej migracji początkowej i skomentuj ją.
Krok 5: Aktualizacja bazy danych
Bez kodu do wykonania w procesie Up, EF utworzy tabelę dbo .__ MigrationHistory z poprawnym wpisem, aby powiedzieć, że poprawnie uruchomił ten skrypt. Idź i sprawdź to, jeśli chcesz. Teraz odkomentuj ten kod i zapisz. Możesz ponownie uruchomić Update-Database, jeśli chcesz sprawdzić, czy EF uważa, że jest aktualny. Nie uruchomi kroku Up ze wszystkimi poleceniami CreateTable, ponieważ uważa, że już to zrobił.
Krok 6: Potwierdź, że EF jest AKTUALNIE aktualny
Jeśli masz kod, do którego jeszcze nie zastosowano migracji, oto co zrobiłem ...
Uruchom „Add-Migration MissingMigrations” Spowoduje to utworzenie praktycznie pustego skryptu. Ponieważ kod już tam był, w rzeczywistości istniały poprawne polecenia do tworzenia tych tabel w początkowym skrypcie migracji, więc po prostu wyciąłem CreateTable i równoważne polecenia drop do metod Up i Down.
Teraz uruchom ponownie Update-Database i obserwuj, jak wykonuje nowy skrypt migracji, tworząc odpowiednie tabele w bazie danych.
Krok 7: Potwierdź ponownie i zatwierdź.
Buduj, testuj, uruchamiaj. Upewnij się, że wszystko działa, a następnie zatwierdź zmiany.
Krok 8: Poinformuj resztę swojego zespołu, jak postępować.
Kiedy następna osoba zaktualizuje się, EF nie będzie wiedział, co go uderzyło, biorąc pod uwagę, że skrypty, które uruchomił wcześniej, nie istnieją. Ale zakładając, że lokalne bazy danych można zdmuchnąć i ponownie utworzyć, wszystko jest w porządku. Będą musieli porzucić lokalną bazę danych i ponownie dodać opcję Utwórz ją z EF. Jeśli mieli lokalne zmiany i oczekujące migracje, zaleciłbym, aby ponownie utworzyli bazę danych na serwerze głównym, przełączyli się na gałąź funkcji i ponownie utworzyli skrypty migracji od podstaw.
DROP DATABASE...