Changed RU context, but without updating database structure

Question

I’m using the free hosting service from mee on a free plan. So far so good, everything worked out in a good.

But after I made some changes to my database, their database just doesn’t work, it keeps on going wrong:

The model backing the 'Entidadescontexto' context has changed Since the database was created. Consider using Code First Migrations to update the database

This has already happened to me on my local machine and I resolved using the command line: Update-Database -Verbose that forces the database to be updated. And with that everything worked right.

I have done this several times on my local machine before putting it on the air, updated the database, but even so their database service accuses that my context has changed and I have not updated (and I have already done this).

Okay, researching I found that answer from Soen which gives as solution proposal add the following line in the Global.asax:

Database.SetInitializer<YourDbContext>(null);

My questions are, how does this work? And there’s another way I can solve this problem (since I don’t have access to the database because I’m using a plan free)?

Answer 1

How it works?

SetInitializer as null indicates to the Entity Framework that the database has no boot class. By default, it is MigrateDatabaseToLatestVersion, which executes all the Migrations pending since last Migration detected until the Migration most recent.

And there’s another way I can solve this problem (since I don’t have access to the database because I’m using a free plan)?

You possibly don’t have EnableAutomaticMigrations configured in the class Configuration inside Migrations, or the MigrateDatabaseToLatestVersion would have solved your problem.

There are three solutions:

1. Generate a Migration Additional

It’s the simplest solution, but the Migration created can come empty. It is rare, but happens.

2. Delete the database and create another

This is more radical. It always works, but requires a backup of the base and a new deploy.

3. Delete all records of __MigrationHistory and do a manual update of the test base for production

This is the boldest solution, and should only be used if you are sure that the schema in production is identical to the development one. Suitable for those who don’t want to have to tear down the base to climb another.