The simplest thing is to change the database schema using EF code

Question

For the first time, I am new to EF code. I have an existing production database, and I first used the EF 4.3.1 code and it worked. Now I just updated my database schema and got an exception

System.InvalidOperationException: The model backing the 'MyDbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269). 

I can’t use DropCreateDatabaseIfModelChanges since it is in production, what is the easiest way to deal with schema changes?

Thanks.

Answer 1

Since EF-CF migrations are a fairly new concept, I would suggest taking a century-old proven process and modifying it to work with our new tools, such as EF. Here is what we do:

• Use DropCreateDatabaseIfModelChanges for local development. This will allow you to synchronize your local copy of the original with you. Model (in code). Each time you create / run, you get an updated local database. You can also use the initializer to load test data, etc. Database.SetInitializer<DBContextNameHere>(new DBContextInitializerNameHere());

• Use the RedGate SQLCompare tool to compare the local developer with production and automatically generate a script change for deployment. (Note: you can also automatically deploy the tool)

http://www.red-gate.com/products/sql-development/sql-compare/index-b

The key advantage is that you do not need to change your local dev process, and you get a duplicate and versioned deployment through the generated script. You can also combine this with the SQL Source management tool to keep all your SQL objects and deployment scripts (even data) in the original management.

NO, I DO NOT DO for these guys, I just love their tool and how it helped me with this very problem.

Answer 2

You can see how to use Entity Framework migrations to automatically update the database according to your new model.

http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

Answer 3

I found that running the following script

 truncate table __MigrationHistory 

in the database removes this problem when your / db code does not sync.

Perhaps I'm just used to the old school, building and messing around with the database design, changing the code accordingly or finding that I need a new field when coding, etc ... just add in both places.

I admit that I am new to (ish) before MVC , but sometimes such functions are useless because they hide how everything works at a fundamental level. When you understand how everything fits together, it’s all good to have generators and tools to help, but at startup ... I don’t think it’s good.

I came across many developers who do not understand simple concepts due to the use of code generators, wizards, etc., when it comes to actually programming or keeping obsolete systems, they are a little lost.

Answer 4

When this happens, I usually start the migration to point to the new database as soon as this database is created, and then compare the structure of the new with the existing one, if necessary, make changes manually (otherwise this may give you an indication of what causes the error - an unintentional change to the schema or index, etc.), then delete the entries in your __MigrationHistory table on your original db and copy the entries from your new db so that __MigrationHistory returns and Code First will now sync correctly.

Answer 5

I solved this problem by adding

 Database.SetInitializer<MyContext>(null); to Application_Start() inside Global.asax.cs 

Answer 6

I hope this code helps you

First EF Code Migration