我使用 Entity Framework Code First 开始我的项目。当我准备好后，我将数据库和代码上传到我的主机提供商。一切顺利。
我需要向我的一个类添加一个新字段，并且我不想丢失数据库中的数据。因此，我尝试关注一些有关使用 Code First 迁移的博客文章。我做了以下事情：
- 我备份了远程（生产）数据库。
- 我在本地附加了这个数据库
- 我将该属性添加到我的班级中
- PM> 启用迁移
- PM> 添加迁移 AddSortOrderToCar
- PM> 更新数据库
- 此时，我创建了本地数据库的 .bak 文件，然后使用该文件“恢复”到远程数据库。
- 最后，我将代码发布到远程站点。
当我访问该网站时，我收到以下错误消息：
自数据库创建以来，支持“blahblah”上下文的模型已经发生了变化。考虑使用 Code First 迁移来更新数据库。
我究竟做错了什么？
根据我的经验，这表明迁移表不同步（即使您的数据不同步），并且它现在已成为数据库模式的一部分（我认为从 4.3 开始 - 在系统表下）。
遇到该错误的原因和方法可能有很多，但大多数时候......
有问题的部分是手动备份/恢复完整数据库与代码更改的某种组合 - 我不完全确定为什么总是这样。
简而言之，即使 Db-s 是相同的迁移表数据也可能不同 - 并且哈希比较可能会失败（仍然完全恢复听起来足够好 - 但你有“两侧”）。
对我有用的是使用
Update-Database -Script
这将创建一个具有“迁移差异”的脚本，
您可以将其作为 SQL 脚本手动应用到目标服务器数据库上（并且您应该插入正确的迁移表行等）。
如果这仍然不起作用 - 你仍然可以做两件事......
删除迁移表（目标 - 在系统表下） - 按照http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx那里的评论 - 这应该会回到以前的行为，如果你确定你的 Db-s 是相同的 - 它只会“信任你”，
作为我使用的最后手段 - 制作一个Update-Database -Script完整模式（例如，通过初始化一个空数据库，这应该强制使用“完整脚本”），
找出INSERT INTO [__MigrationHistory]记录，
只需运行它们，将它们插入数据库，
并确保您的数据库和代码匹配，
这应该会使事情再次同步运行。
（免责声明：这并不是始终有效的防弹方案，根据您当地的情况，您可能需要尝试一些事情 - 但应该让您保持同步）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
