MVC3 和 Code First 迁移——“自创建数据库以来，支持 'blah' 上下文的模型已更改" [英] MVC3 and Code First Migrations - "model backing the 'blah' context has changed since the database was created"
问题描述
我使用 Entity Framework Code First 开始了我的项目.当我准备好时，我将我的数据库和代码上传到我的主机提供商.一切正常.
I started off my project by using Entity Framework Code First. When I was ready I uploaded my database and code to my host provider. Everything worked.
我需要向我的一个类添加一个新字段，但我不想丢失数据库中的数据.因此，我尝试关注一些关于使用 Code First Migrations 的博客文章.我做了以下事情:
I need to add a new field to one of my classes and I don't want to loose the data in the database. Thus, I tried following some blog posts about using Code First Migrations. I did the following:
- 我备份了我的远程(生产)数据库.
- 我在本地附加了这个数据库
- 我已将该属性添加到我的班级
- PM> 启用迁移
- PM> 添加迁移 AddSortOrderToCar
- PM> 更新数据库
- 此时我创建了本地数据库的 .bak 文件，然后使用该文件恢复"到远程数据库.
- 最后，我将代码发布到远程站点.
当我访问该站点时，我收到以下错误消息:自数据库创建以来，支持blahblah"上下文的模型已更改.考虑使用 Code First 迁移来更新数据库.
When I visit the site I get the following error message: The model backing the 'blahblah' context has changed since the database was created. Consider using Code First Migrations to update the database.
我做错了什么?
推荐答案
根据我的经验，这表明迁移表不同步(即使您的数据不同步)，现在它已成为 db 架构的一部分(因为4.3 我认为 - 在系统表下).
From my experience that suggests that migration table is out of sync (even if your data isn't), and that's been part of the db schema now (since 4.3 I think - under system tables).
遇到该错误的原因和方式可能有很多，但大多数情况下...
There could be many reasons and ways to experience that error , but most of the time...
有问题的部分是手动支持/恢复完整数据库与代码更改的某种组合 - 我不完全确定为什么总是这样.
The problematic part is some combination of manually backing/restoring the full database with code changes alongside - I'm not entirely certain as to why always.
简而言之，即使 Db-s 是相同的迁移表数据也可能不是 - 并且哈希比较可能会失败(仍然完全恢复听起来已经足够了 - 但你有两个方面").
In short, even if Db-s are the same migration table data might not be - and hash comparison may fail (still full restore sounds like good enough - but you have 'two sides').
对我有用的是使用更新-数据库-脚本
这会创建一个带有迁移差异"的脚本，
您可以将其作为 SQL 脚本手动应用到目标服务器数据库上(并且您应该插入正确的迁移表行等).
That creates a script with a 'migration difference',
which you can manually apply as an SQL script on the target server database (and you should get the right migration table rows inserted etc.).
如果这仍然不起作用 - 你仍然可以做两件事......
If that still doesn't work - you can still do two things...
删除迁移表(目标 - 在系统表下) - 根据 http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx 评论 - 这应该会回到以前的行为，如果你确定你的 Db-s 是相同的 - 它只会信任你"，
Remove the migration table (target - under system tables) - as per http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx comments in there - that should fail back to previous behavior and if you're certain that your Db-s are the same - it's just going to 'trust you',
作为最后的手段，我使用了 - 制作完整架构的 Update-Database -Script(例如，通过初始化一个应该强制完整脚本"的空数据库)，
找到INSERT INTO [__MigrationHistory] 记录，
只需运行这些，将它们插入到数据库中，
并确保您的数据库 - 和代码匹配，
As a last resort I used - make a Update-Database -Script of the full schema (e.g. by initializing an empty db which should force a 'full script'),
find the INSERT INTO [__MigrationHistory] records,
just run those, insert them into the database,
and make sure that your databases - and code match,
这应该使事情再次同步运行.
that should make things run in sync again.
(免责声明:这不是始终有效的防弹措施，您可能需要根据当地情况尝试一些方法 - 但应该让您保持同步)
(disclaimer: this is not a bullet proof to work at all times, you may need to try a few things given your local scenarios - but should get you in sync)
这篇关于MVC3 和 Code First 迁移——“自创建数据库以来，支持 'blah' 上下文的模型已更改"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
