I'm having lots of trouble trying to figure out how to rebuild my database.
I've deleted a table, then i ran this command update-Database -Verbose and it doesn't rebuild my database.
The same thing goes for when i have a table, then i change a column name inside my Model (C#) and then i want to rebuild my database so that the name shows up in the database, and nothing happens when i run the same command.
How can i rebuild my database? I'm sure there's a command or something, besides the update-Database -Verbose.
I'm using Visual Studio express 2012 for Web.
EDIT: Couldn't find a command able to rebuild my Database, though i did find a simple way to do what i wanted.
You can delete tables or rename columns, in your Models, and it will always rebuild your database. In the Solution explorer, you'll find an icon that says "Show All Files", press it and open the folder App_Data, there you'll see your database file, delete it and re-run your application, and it will build again the Database, with all the changes you've made to your Models in your code. So that part about changing catalog and .mdf names in the Web.config file is not needed.
Update-Database is part of the Entity Framework Migrations package, which allows you to script the changes to the database sequentially. The command won't do anything on it's own without migrations to process. If you are using Migrations, you need to use the Add-Migration myNewMigration command first, and verify the script that is generated makes sense.
If you are not using Migrations, you can use the much simpler database options such as DropCreateDatabaseIfModelChanges() against your context class.
Another thing you can try is running Update-Database -f to "force" the migration to run even if it's already present in the _MigrationHistory
Related
I am working on an application that utilizes a database that often has tables added to it or modified. Is there a way I can regenerate the .edmx file as a build step or during compile time to add these new tables/modifications without manually running the wizard?
You can try to run sql scripts to insert/modify tables during build process.
Related extension:
ExecuteSqlScript
Run SQL Server Scripts Task
Or directly use PowerShell to Execute .SQL Files from Directory.
Reference below articles to change the database during build/release:
Build and Release Process for SQL Server Database
Scripts using Online TFS
Continuous Deployment of SQL Server Database Changes using Visual
Studio & TFS Release Manager
UPDATE:
Choosing the Update Model from Database is the best method for updating your EDMX. There are certain properties that don't get updated on the Conceptual layer.
See How do you update an edmx file with database changes?
Seems there isn't a good way to achieve that, however if the actions can be executed in command line, then we can add a step to run the command or script.
I'm using EF 6 and when I run Update-Database it is trying to apply every migration since the beginning of the project, even though there is only migration that is new.
If I attempt to create an empty migration, I get an error that says I can't create a new migration because there are explicit migrations pending.
The only blog post I found with a similar issue suggested dropping the __MigrationHistory table and doing Update-Database -Script, stripping out all the actual DB changes but leaving in the Create __MigrationHistory and Migration Inserts. I didn't drop the table, but I did rename it, and this didn't solve the problem for me.
This question looks like a duplicate, but when I run the script I see that my context key has not changed, so that's not my problem.
What's weird is I added a column to my model, and then did an add-migration with no problem. Then I went to lunch (but without doing an update-database), then after lunch I decided to add another column to my model and when I did add-migration -force again this error started. I've completely rolled back my workspace (completely delete the workspace and removed all code from my machine), but the problem persists.
I am in a team environment, but we each use our own dev databases, and I've verified the connection string is correct in my Migrations App.Config file.
I ran SQL Profiler during the Update-Database -Script command, and it ran the following query 24 times before giving up (12 batches of 2) :
IF db_id(N'ISEPDBContexts.AdministratorDb') IS NOT NULL SELECT 1 ELSE SELECT Count(*) FROM sys.databases WHERE [name]=N'ISEPDBContexts.AdministratorDb'
Which is weird because that's the name of my connection string, not the name of the database.
Turns out the problem was that Package Manager Console wasn't looking at my config file, so a quick search and I found that you have to not only set the Default Project in PMC (which I was doing), but the solution has to have the same project selected as Startup Project. (Credit)
Before anyone marks this as a duplicate, none of the questions similar to this addressed any of my concerns or answered any of my questions.
I am currently developing all the POCOs and data contexts in a library project, and running migrations from within this project. The database I'm updating is the development database.
What do I do if I want to create the current schema to a fresh, new database? I figure that all I have to do is to change the connection string in web.config and run Update-Database, correct?
While the live/production database is up and running, I want to add new columns and new tables to the schema, and test it out in development. So I switch back the connection string to the development database's connection string, and run Update-Database.
Going back and forth between two databases seems like I'll get conflicts between _MigrationHistory tables and the auto-generated migration scripts.
Is it safe to manually delete the _MigrationHistory tables in both databases, and/or delete the migration files in /Migrations (so I'll run Add-Migration again)? How do we manage this?
What do I do if I want to create the current schema to a fresh, new database?
- Yes, to create fresh database to the current migration level you simply modify the connection string to point to a database that does not yet exist and run update-database. It will run all the migrations in order.
As far as migrating to the Production database, I am running the update-database command with the -script switch to acquire the raw sql and then applying that script to the production database manually. This is helpful if you need to keep a record of sql commands run against the database as well. Additionally, you can generate the script explicitly from a specific migration to another specific migration via some of the other update-database switches.
Alternatively, you can create an Idempotent script that works from any migration by using the–SourceMigration $InitialDatabase switch and optionally specify an end migration with –TargetMigration
If you delete the _MigrationHistory tables you will have issues where the generated script will be trying to add columns that already exist and such.
You may find the following link helpful:
Microsoft Entity Framework Migrations
I would suggest having a separate trunk in your source code repository - one pointing to production and one to development to avoid risks of switching between the two in visual studio.
Me also had the same problem, even when using one and the same database - due to some merges in the repository, and the mix of automatic/manual migrations. For some reason the EF was not taking into account the target database, and calculating what scripts need to me executed, based on what is already in the database.
To fix this, I go to the [__MigrationHistory] table on the target database and get the latest migration name. This will help EF to determinate the state of the DB, and will execute just the scripts needed.
then the following script is run:
update-database -script -sourcemigration {latest migration name}
This creates update script that is specific to the target database (the connection string should be correct, as discussed in the other comments)
you can also use -force parameter if needed
this way you can update any database to latest version, no mater in what version you found it, if it has MigrationHistory table.
Hope this helps
My production and my developmental database went out of synch and it gave me endless problems. I solved it using a tool from Red-Gate to match up the databases. After using the tool, the databases were exactly the same but my migration was not working and I started to get odd errors i.e. trying to add tables/ columns that already existed etc. I solved that. I just deleted the migration folder on the local, recreated it, added the initial migration, updated the database and then matched the data of this migration file (local) to the one on the host (delete all the data in the migration file on the host, and add the same data that is on the local into the host). A more detailed explanation is at:
migration synch developmental and production databases
I'm trying to get Entity framework migrations working. I've enabled code first migrations, its created a migrations folder, config file and the mig history table, but no initial create. Am i missing a step? This is a new db created by EF (4.3.1).
This behavior is not in place by default, but it is available to you easily in many different forms.
You can call context.Database.CreateIfNotExists(); at application startup.
You can use one of the built-in DatabaseInitializers. The CreateDatabaseIfNotExists initializer is built into EntityFramework and just needs to be added to your project.
You could create your own custom database initializer which includes option #1 inside of itself. Example: Code First Migrations and initialization
You can include DatabaseInitializers in your project either by code or via a config file.
Include an EntityFramework Database Initializer via code:
In your application startup you can setup the DatabaseInitializer like so:
System.Data.Entity.Database.SetInitializer<DairyMmmContext>(new System.Data.Entity.CreateDatabaseIfNotExists<DairyMmmContext>());
NOTE: this code has changed multiple times throughout the life of entityframework! This example is for EF 4.3 which is the current production release available via nuget.
Include an EntityFramework Database Initializer via configuration element:
<configuration>
<entityFramework>
<contexts>
<context type="MyNamespace.MyEFDataContext, AssemblyName">
<databaseInitializer
type="System.Data.Entity.CreateDatabaseIfNotExists`2[[MyNamespace.MyEFDataContext, AssemblyName],
[MyNamespace.Migrations.Configuration, AssemblyName]], EntityFramework" />
</context>
</contexts>
</entityFramework>
</configuration>
You'll notice this can be a little "ungraceful" with this configuration. You need to replace AssemblyName above with the name of the assembly you keep your entityframework stuff in, replace MyNamespace.MyEFDataContext with the fully qualified name of your entityframework data context, and replace MyNamespace.Migrations.Configuration with the fully qualified name to your configuration class (by default in the Migration folder inside your project).
EDIT: Edited to respond to additional comments
A migration is a change from one schema definition to another schema definition. Creating the empty database is not a migration (but everything after that is). There will be no migration source file in your project for just creating an empty db, that is done in code by the initializer.
If you are already using the DropCreateDatabaseAlways initializer it should be doing that. However, I noticed you are setting the initializer in code which means there is the opportunity for a timing problem (setting the initializer after your context is already past the point of calling any initializers).
You can force entityframework to run your initializer at any point in code with context.Database.Initialize(true); (The parameter is a true/false to force the initialization regardless of the current state). That would drop and recreate your database every time.
But you can also just make sure your initializer is setup as early as possible in your application's life cycle (before you have created a single instance of your context).
"Initial Create" is NOT created automatically! You need to create that yourself. Some tutorials of EF are confusing and I had the same misunderstanding as you.
What you need to do:
-Add-Migration InitialModel
If you already have created your database tables and domain model, then:
-Add-Migration InitialModel -IgnoreChanges
From this point, your code will be in sync with database. Anytime you change the code, you can use Add-Migration to add the changes to your database.
The article / tutorial here here (on microsoft.com)
describes the reason that an initialCreate migration doesn't exist. The migration will only be added if the Database already exists. Otherwise, the first migration will be the 'initialCreate' as there is no point in creating a migration to a Database that doesn't exist yet... no DB means there is nothing to roll back to, on a down migration.
Here is the pertinent paragraph:
Run the Enable-Migrations command in Package Manager Console
This command has added a Migrations folder to our project, this new folder contains two files:
The Configuration class. This class allows you to configure how Migrations behaves for your context. For this walkthrough we will just use the default configuration.
Because there is just a single Code First context in your project, Enable-Migrations has automatically filled in the context type this configuration applies to.
An InitialCreate migration. This migration was generated because we already had Code First create a database for us, before we enabled migrations. The code in this scaffolded migration represents the objects that have already been created in the database. In our case that is the Blog table with a BlogId and Name columns. The filename includes a timestamp to help with ordering.
If the database had not already been created this InitialCreate migration would not have been added to the project. Instead, the first time we call Add-Migration the code to create these tables would be scaffolded to a new migration.
Not sure it's the same but I had a similar issue. I think my problem was related to the fact that I dont use a connections string from the config file to get my connection string.
Fiddling with the start up project in the solution and also the projet combo in the Package Manager Console I was able to generate that first migration.
Also make shure you have a connections string with the name of your dbContext class so the Package Manager can find it.
I am using EF 6 RC1 and ran into this problem where neither the InitialCreate nor __MigrationHistory were being created when running Enable-Migrations.
Actually, just after upgrading from EF 5 to EF 6 I ran Enable-Migrations and for some reason it created a __MigrationHistory table using the EF 5 schema, so I deleted it and my Migrations directory and tried to start over.
But every time I deleted the Migrations directory it wouldn't create an InitialCreate or __MigrationHistory. I tried dropping and recreating the database and restarting Visual Studio 2012 to no avail. I gave up for the day and the next morning tried again - after letting my computer sit for about 8 hours it then created the InitialCreate. I am guessing there must be a cache somewhere that has a really long timeout - anyone? I am also guessing that rebooting might clear the cache, but I didn't try that.
Whatever the case, it is possible to use PM> Add-Migration InitialCreate to do that step manually.
Anyway, I still didn't get a __MigrationHistory table. Apparently, EF 6 has changed from creating it during the Enable-Migrations command to instead only creating it during the Update-Database command. And since my schema had already been created at that point, I needed to tear it down and recreate it manually:
PM> Update-Database -TargetMigration:0
PM> Update-Database
I also stopped after the first command to check the state of the database to ensure I was updating the correct one, since according to this, the database connection string is picked up or autogenerated depending on the configuration, and unless it is configured right, there is no guarantee you are going to access the database or instance of SQL Server you intend to.
After running both commands it created a __MigrationHistory table - and it didn't create it as a system table (which I didn't really want anyway), so all is good. Not exactly the same problem as the OP, but hopefully this will be helpful to someone else.
References:
http://elegantcode.com/2012/04/12/entity-framework-migrations-tips/
Reset Entity-Framework Migrations
How to recreate migrations from scratch
I know this is old, but there is no accepted answer and I had same issue.
The trick is Enable-Migrations command. As stated here there is a command Enable-Migrations –EnableAutomaticMigrations. What it does it starts migrations exactly where you are.
If you want the first migration to be creation of database, just run Enable-Migrations (without --EnableAutomaticMigrations).
And remember to set initializer:
Database.SetInitializer(new MigrateDatabaseToLatestVersion<LicenseContext, Configuration>());
It looks like CodeFirst stops doing its homework when it doesn't have full control of the database (I suppose).
The scenario is a web site hosted on Arvixe.com (or I suppose any other shared hosting server), where I have to create databases only from their control panel (and NOT with Sql Server Management Studio, just to say...).
Once created an empty database, I register a connection in the web site, and I use it to generate database from poco objects like in:
add-migration m1 -targetdatabase myconnection
This generates correctly my FIRST migration, that I can apply without problems with
update-database -targetdatabase myconnection
The first concern, not too important, is that since the database is existing, it will NOT issue the Seed command, so I have to insert my first records by hand, but this is not a great problem.
Then I change my poco objects, and I need to update the database, but when I issue ANOTHER
add-migration m2 -targetdatabase myconnection
it gives the error:
System.Data.Entity.Migrations.MigrationsPendingException: Unable to generate an explicit migration because the following explicit migrations are pending: [201111081426466_m1]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
This is really strange, since if I look at the database, I can see even the table __MigrationHistory, but then it looks like it cannot recognize it...
Anyone with the same problem, or some good tip to where investigate?
Thanks in advance,
Andrea Bioli
I had this problem. I was able to resolve it by providing a connectionString and a connectionProviderName parameter to both the Update-Database and the Add-Migration commands.
If you have many projects in your solution with multiple config files, Package Manager seems to be confused. In my case, I had one project selected as the default project for Package Manager Console, but it was pulling the connection string from the Visual Studio solution default start-up project instead.