88

I want to know how to run the 'Update-Database' command for a production database.

The 'Update-Database' database works fine from my local machine, but how do I get this to work for production data?

So, if I make a change to my application and then run the 'publish' through Visual Studio this works fine for the code side of things, but how do I run the 'Update-Database' command for the production data?

Hope this question makes sense...

Thanks.

Arad Alvand
  • 8,607
  • 10
  • 51
  • 71
haydnD
  • 2,225
  • 5
  • 27
  • 61
  • 2
    Possible duplicate of [Using Entity Framework (code first) migrations in production](http://stackoverflow.com/questions/10848746/using-entity-framework-code-first-migrations-in-production) – Owen Pauling Jun 07 '16 at 14:31
  • 1
    You can use the provided migrate.exe it is in the installed Nuget package. See usage: https://msdn.microsoft.com/en-us/library/jj618307(v=vs.113).aspx – Major Jun 05 '18 at 10:26

6 Answers6

36

See Using Entity Framework (code first) migrations in production so that your application automatically updates the database when Entity Framework initializes.

Now if you're more comfortable having manual control over the migration, you could use the -Script argument to the Update-Database command on your developer machine to generate SQL scripts which you can then run against the production database.

http://msdn.microsoft.com/en-us/data/jj591621.aspx (see Getting A SQL Script section)

Arad Alvand
  • 8,607
  • 10
  • 51
  • 71
David Moore
  • 2,466
  • 22
  • 13
27

To add on what @David said already...

Personally, I don't trust automatic updates in 'live' scenarios, and I always prefer manual database administration (i.e. there is a problem with permissions needed to create or alter Db - not to mention shared hosting etc.) - but from what I've seen migrations are pretty solid when it comes to synchronizing (in fact, the only way to 'untie' them normally is to remove the Db and force full/fresh update).

Here is a post I made a while ago on how to script and synchronize database / code and geared towards deployment scenarios (and when problems arise). It doesn't apply to you (yet) but something to keep in mind.

MVC3 and Code First Migrations - "model backing the 'blah' context has changed since the database was created"

Community
  • 1
  • 1
NSGaga-mostly-inactive
  • 14,052
  • 3
  • 41
  • 51
  • 2
    Why so complicated? What's wrong with simply running the migration code automatically when the application starts up / uses the context for the first time? How is a SQL script better than calling a C# method? – Florian Winter Apr 03 '17 at 11:55
  • 3
    @FlorianWinter true in ideal conditions and relatively simple scenarios, and if you know what you're doing (e.g. db administration and migration table). But sooner rather than later you hit some issues, gets out of sync etc. And you have live data in there that mustn't be touched at all cost. I really do not trust migrations or any initializer to do that work for me. And that comes from myriad of issues that I've seen over the years. So when w live data, I like to be in full control. I can let the app run and "migrate itself" but only after I rechecked. And scaling etc. – NSGaga-mostly-inactive Apr 04 '17 at 13:34
  • Point taken, and I agree. I will add a warning and a link your your answer to my answer, but I will leave it there, because those simple scenarios do exist. At least temporarily... – Florian Winter Apr 04 '17 at 13:46
7

Do you just want to automatically update the database to the latest version when and where ever your application runs (development and production)?

This may not be a good idea, except in very simple scenarios where you know you can trust automatic migration and manually migrating the database(s) is not feasible. Please see this answer: https://stackoverflow.com/a/15718190/2279059 . If you disregard this warning, read on.

Add the following to web.config:

<entityFramework>
<contexts>
  <context type="MyAssembly.MyContext, MyAssembly" disableDatabaseInitialization="false">
    <databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[MyAssembly.MyContext, MyAssembly], [MyAssembly.Migrations.Configuration, MyAssembly]], EntityFramework" />
  </context>
</contexts>

This may look scary, but it does basically the same as the following code:

Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, Migrations.Configuration>());

If you have no luck with web.config, then you may also try to put this code into Global.asax. I personally prefer configuration over code.

If you want your config file to look cleaner, you can also derive a new class from the template MigrateDatabaseToLatestVersion class so you don't need to use the cryptic syntax for passing type arguments in your web.cofig file:

public class MyDatabaseInitializer : public MigrateDatabaseToLatestVersion<MyContext, Migrations.Configuration> {}

What this does is to set a database initializer which automatically updates the database to the latest version.

(Source and more details: Entity Framework Code First Web.config Initialization)

Florian Winter
  • 4,750
  • 1
  • 44
  • 69
5

You can run the Update-Database EF Tools command using the Production connection string as follows:

Update-Database -Args '--environment Production'

Source: https://learn.microsoft.com/en-us/ef/core/cli/powershell#aspnet-core-environment

As stated by others, you have to be extra careful, you should definitely try it first on a Staging environment.

M. Ruiz
  • 406
  • 4
  • 11
0

Another solution that has worked for me was this: In my local web.config file, I set the connection string to point to the production server.

Then all the PM Console commands will be run on the production server. I can update-database or revert migrations as needed, and the changes will apply to the production database.

Gimmly
  • 443
  • 1
  • 6
  • 15
0

I find update-database -Connection "your-connect-string" works to update a test or staging database. (EF5 onwards)

Stuart Helwig
  • 9,318
  • 8
  • 51
  • 67