web-dev-qa-db-fra.com

MVC3 et Code First Migrations - "le modèle sauvegardant le contexte 'blah' a changé depuis la création de la base de données"

J'ai commencé mon projet en utilisant Entity Framework Code First. Quand j'étais prêt, j'ai téléchargé ma base de données et mon code sur mon fournisseur d'hôte. Tout a fonctionné.

Je dois ajouter un nouveau champ à l'une de mes classes et je ne veux pas perdre les données de la base de données. Ainsi, j'ai essayé de suivre quelques articles de blog sur l'utilisation de Code First Migrations. J'ai fait ce qui suit:

  1. J'ai sauvegardé ma base de données distante (de production).
  2. J'ai attaché cette base de données localement
  3. J'ai ajouté la propriété à ma classe
  4. PM> Activer les migrations
  5. PM> Add-Migration AddSortOrderToCar
  6. PM> Base de données de mise à jour
  7. À ce stade, j'ai créé un fichier .bak de la base de données locale, puis utilisé ce fichier pour "restaurer" la base de données distante.
  8. Enfin, j'ai publié le code sur le site distant.

Lorsque je visite le site, le message d'erreur suivant s'affiche: Le modèle correspondant au contexte "blahblah" a changé depuis la création de la base de données. Pensez à utiliser Code First Migrations pour mettre à jour la base de données.

Qu'est-ce que je fais mal?

entity-frameworkasp.net-mvc-3ef-migrations
19
Scott Dietrich

D'après mon expérience, cela suggère que la table de migration est désynchronisée (même si vos données ne le sont pas), et cela fait maintenant partie du schéma de base de données (depuis la version 4.3, je pense - sous les tables système). 

Il peut y avoir plusieurs raisons et manières de vivre cette erreur, mais la plupart du temps ... 

La partie problématique est une combinaison de sauvegarde/restauration manuelle de la base de données complète avec les modifications de code, je ne suis pas tout à fait sûr de savoir pourquoi. 

En bref, même si les bases de données sont identiques, les données de la table de migration risquent de ne pas être - et la comparaison de hachage peut échouer (une restauration complète semble tout de même suffisante - mais vous avez deux faces »). 

Ce qui fonctionne pour moi est d'utiliser
Update-Database -Script 

Cela crée un script avec une «différence de migration»,
que vous pouvez appliquer manuellement en tant que script SQL sur la base de données du serveur cible (et vous devez insérer les bonnes lignes dans le tableau de migration, etc.). 

Si cela ne fonctionne toujours pas, vous pouvez toujours faire deux choses ... 

  1. Supprimez la table de migration (cible - sous les tables système) - conformément à http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough. aspx commentaires dedans - cela devrait revenir au comportement précédent et si vous êtes certain que vos Db-s sont les mêmes - il ne fera que "vous faire confiance", 

  2. En dernier recours, j'ai utilisé - créer un Update-Database -Script du schéma complet (par exemple, en initialisant une base de données vide qui devrait forcer un "script complet"),
    trouver les enregistrements INSERT INTO [__MigrationHistory],
    il suffit de les exécuter, de les insérer dans la base de données,
    et assurez-vous que vos bases de données - et le code correspondent,

cela devrait rendre les choses à nouveau synchronisées. 

(Avertissement: ce n'est pas une épreuve à toute épreuve pour fonctionner à tout moment, vous devrez peut-être essayer quelques petites choses en fonction de vos scénarios locaux - mais vous devriez vous mettre en phase.)

25
NSGaga

Je pense qu'à l'étape 6, vous devez exécuter Update-Database -Verbose.

De plus, ce lien est très utile pour mettre à jour la base de données dans EF avec Scaffolding http://www.asp.net/mvc/overview/older-versions/hands-on-labs/aspnet-mvc-4-entity- cadre-échafaudage-et-migrations

0
srinced