I have an EF code first model generated by reverse engineering an existing database - one of the supported core scenarios for EF 6.
I now have updates to the DB and I want to reflect those in the model, but I simply cannot find a mechanism to update the generated model. In the "old" EDMX world, I could update model from database, but I cannot see how to do this in VS 2013 with EF 6?
I have tried to run a migration against the new database but no changes were made to the POCOs.
To update your database in code first projects, do the following:
Find out the name of the database context by checking your source code, in the following steps I assume it is ConfigDbContext
Open PM console via menu Tools -> NUGET Package Manager -> Package Manager Console
Type the following: PM> add-migration nameofmigration -context ConfigDbContext PM> update-database -context ConfigDbContextNote: Replace nameofmigration by any unique name of your choice so you easily remember the changes. The migration code will be named with a timestamp and this name.
If you got a success message, open SQL Management Studio, connect to your database, or, if you have it already open, refresh and review the changes.
Note: If you're getting a message that you should update EF core tools, here is how you can do that. For example:
PM> Install-Package Microsoft.EntityFrameworkCore.Tools -Version 2.2.0
Replace the version number 2.2.0 by the newer version you get displayed in the warning.
Related
I modified a property in the model and it turned out it is not supported by the version of SQLite. This is the error. {"SQLite does not support this migration operation ('DropColumnOperation'). For more information, see http://go.microsoft.com/fwlink/?LinkId=723262."}
So I decided to roll it back by using the command Update-Database Migration "MyFirstMigration" but an error shows up on the console which states Update-Database shouldn't be used with Universal Windows Platform apps. Instead, call DbContext.Database.Migrate() at runtime.. This code recommended is already the code executed at the first run of the application that generates the first error above.
I am really going into circle here. Can someone suggest how I can rollback/downgrade MySecondMigration ti MyFirstMigration?
Can someone suggest how I can rollback/downgrade MySecondMigration ti MyFirstMigration?
For the same DbContext, just execute Remove-Migration command on your package manager console, it will remove the last migration of this DbContext. It is your MySecondMigration which will be removed and only MyFirstMigration left.
Update-Database shouldn't be used with Universal Windows Platform apps. Instead, call DbContext.Database.Migrate() at runtime
For this, just as this error shown, DbContext.Database.Migrate() applies any pending migrations for the context to the database, include what Update-Database did (Updates the database to a specified migration). By testing on my side, for the same DbContext, every new migration is the updating based on the old one. DbContext.Database.Migrate() will apply all the migrations for updating. If you don't want the latest update, just remove it for roll back.
I am working with Entity Framework code first.
I have managed to work with migrations, but i need to type commands in the Package Manager Console.
(for example Update-Database command).
It works fine, but it works on my developpemnt computer.
Now, imagine i have a lot of production server. Some of those servers are still in database version 1, others in version 3 and the lastest version is 5.
Is it possible to run the equivalent of Update-Database Command from C# Code ?
DbUp is one other open source tool which is effective and provides robust features to perform production DB upgrade in EF Code first approach.
Here is an informative article comparing the Dbup open source tool vs EF migration feature.
Yes,you can do that.You have to change your web.config file's connection string according to your production server and then run :
PM> Update-Database
Update : to generate scripts.
PM > Update-Database -Script -SourceMigration: $InitialDatabase -TargetMigration:
AddPostAbstract
You can refer this for more info : Getting a SQL Script
I am currently playing with beta4 of EF7 using the blank ASP.NET web project template.
After having kicked off the existing migration, resulting in the tables being created in the localdb, the following occurs:
Strangely, when I clean up the migration-folder, including removing ApplicationDbContextModelSnapshot.cs and I run
dnx . ef migration add twice, I get the following error:
dnx : System.InvalidOperationException: No data stores are configured. Configure a data store by overriding OnConfiguring in your DbContext class or in the AddDbContext method when setting up services.
The second migration is not created. When I review the created migration it contains all tables whereas the database is already provisioned, so you should expect the migration being empty.
Then, when I remove the first migration and run the add migration command again more than once, all the migrations are correctly created, i.e. as empty files.
Can someone explain this to me? Is this expected behavior or is this a bug in beta4?
Tip for people coming from former EF-versions:
* Don't use the K command framework anymore.
* Don't use the Add-Migration cmdlets anymore.
Both have been replaced by dnx . (dot). (dnx = .NET execution environment)
Some references:
https://github.com/aspnet/EntityFramework/wiki/Entity-Framework-Design-Meeting-Notes---September-11,-2014
http://jameschambers.com/2015/05/project-k-dnvm-dnx-dnu-and-entity-framework-7-for-bonus-points/
Remove the constructor of ApplicationContext. It is a temporary workaround to enable deployment, but it interferes with the Migrations commands.
I am using Beta 3 of EF power tools for EF5.0 to reverse engineer an existing database.
When I select "Reverse engineer code first" from the project context menu, I get all the models and the DBContexts + mapping as expected. And all looks good.
I enabled Migrations successfully immediately after the reverse engineering process completed.
However I want to add a new property to one of the models. After adding the new property,
I run PM> Add-Migration AddMyPropertyToMyTable
a Migration file is created,
If I then try PM> Update-Database
I get an error telling me that the tables already exist.
I am following the tutorial here:> http://msdn.microsoft.com/en-us/data/jj200620
Why am I getting this error? of course the table exists, I just reverse engineered it
Am I supposed to delete the database after reverse engineering? Or in the case of a reverse engineered Db, do I have to make my changes to the actual database and just reveres engineer it again to get the desired changes in my project (so what's the point of reverse engineering in the first place?)
is there something missing from the tutorial, i.e. an extra step required to make the database updateable after model changes?
When you enabled migrations with the existing database, EF didn't add the __MigrationHistory table or initial migration (DbMigration) file.
You can add an initial migration by using the following in the package manager console:
Add-Migration Initial -IgnoreChanges
This will be an empty initial migration. Then to force EF to create the __MigrationHistory table, you can use:
update-database
This should then create the __MigrationHistory table (under System Tables)
You should now be able to make model changes, and create new migration files (or use automatic migrations by configuring it in your Configuration.cs file under the Migrations folder).
You can run these migration changes by hand by using update-database, or have the database automatically migrated to the latest migration on application startup by using the MigrateDatabaseToLatestVersion initializer.
You can set this in the app.config/web.config so that it isn't set in production for example.
Using Entity Framework 5 code first, I'm wondering how EF Migrations decides that the target database is at a certain migration version? That is, I've emptied my database (deleted all tables) and am trying to re-do the initial migration via the following command (in the PM console): update-database -targetmigration 201212011907118_Initial. update-database then responds with 'Target database is already at version 201212011907118_Initial'.
Apparently, Code First Migrations maintains a table called 'dbo.__MigrationHistory' in which it stores metadata about applied migrations. This is a system table, which makes it difficult to e.g. delete. See this post for reference.