In my Application I have used Entity Framework Database First approach.
Currently my application is in Dev Environment, now it need to be moved into Test Environment and later into Production Environment.
So is there anyway that I can use .net feature or Entity framework feature to migrate/create database in Test environment. Other than using SQL feature of restoring the database.
Also note that if any enhancement comes then Database structure can change, table schema can change.
So can you suggest me the best way to easily migrate database schema in different environment without losing existing Data.
If you want to take advantage of EF-Migrations feature, you must convert your application to Code First with Existing Database http://msdn.microsoft.com/en-us/data/jj200620.aspx
If you are unable to convert to code first then you must create the update script by hand.
Use a schema compare tool, compare the development and production server.
For each difference found, create an update query.
Once the entire script is finished, test it on the staging server.
Automating the migration is very risky, it depends on the type and size changes you made to the schema. You can't trust any single feature or tool specially if the changes requires data motion (moving data around).
The following links might help you:
How to do Migrations in DB first approach
EF Migrations for Database-first approach?
With Database First, the easiest way to copy a schema is to extract a data tier application in management studio, create an empty database on the target, register it as a data tier application with the same name, and upgrade the empty database using the upgraded file. You can repeat this step to manage schema changes.
Having said that, going forward you're really better off switching your Database First to Code First as it will make change management across your deployments much easier.
Migrations are best way to deal with it
Preferred way to update production db is to first generate sql file and then run the sql file in production environment.
MS had a very good artical on this
http://msdn.microsoft.com/en-in/data/jj591621.aspx#script
Related
I'm currently working on a database that comes with a legacy project which uses EntityFramework (updates code based on existing database using Data Model Designer)
Currently I work on the master copy and our developers work locally using SQL Server merge-replications on their local PC.
Issue here is that we recently started doing some change work that modifies the database schema, so when we use schema comparison (visual studio SQL compare feature), there are huge number of replication sp & schema changes that basically if I do update it will corrupt the live database. So my current solution is remove the dev server replication (so that the schema goes back to what it should look like without replication changes), then do the schema compare & update, and then create a new merge replication again so our developers can continue working on the dev db.
I thought it was just one-off db schema change, but just realized it will be continuous changes at least for the next 3-6 months, so that basically make each release a big headache (if it can be called as a 'release' prep...)
My SQL & EntityFramework knowledge is limited, can anyone shed some light on this for me please?
Thanks in advance!
Whats the observed need behind merge replication in the dev environment? I understand the need for devs to have a local copy they can mess with, run tests against etc, but I'm lost on why a full Publisher-Subscriber model is needed to synchronize DB state in a dev/test environment, and it seems to be causing you more problems than it may solve given the schema is going to be malleable for a few months.
If merge replication is not a hard requirement for the dev environment, I would suggest you replace it with an alternate method of distributing changes to the local copies. If the devs are working with a full copy of the DB anyway, I see no reason not to write a script that backs up the master copy on the dev server, then pulls that file down and restores it locally. Then, changes to that schema would be accomplished with change scripts, which can be run and tested locally before being applied to the master DB, then distributed on-demand with another run of the backup/restore script.
It's a slightly more manual process and an older way to work with DBs, but it seems far more palatable to me than breaking and re-establishing replication regularly. It'll require some collaboration to make sure devs aren't trying to make a backup at the same time or making conflicting changes to local copies that will blow up on the master copy; your devs ideally should be talking to each other anyway about this kind of thing, and you might make the script smart enough to look for a recent backup before generating another.
One more thought, don't know how feasible it is given your progress to date; it's not impossible to switch from DB-First to Code-First. The conversion is basically a hybrid process of Database First and Code First; the DB is reverse-engineered as a one-time operation to generate a model similar to DB First, but instead of EDMX files, the model is written out to source code files, and changes to those model files or to mapping conventions on the context can then be aggregated and applied to the schema as migrations in typical Code First style. Assuming you prepare the live DB for migrations as well (and have the live DB in the same state as the master Dev DB prior to the model generation), this even removes the requirement of a SQL compare and update; you just apply the migrations to the live DB, same as you would to any Dev instance. The only potential gotcha is that some migrations can be written destructively, so you have to make sure what you're about to apply isn't going to clear out all the fields in a renamed column.
I have an existing ASP.Net Web Forms application which is using EF Code First with Existing Database i.e. I am using EF classes and DbContext to point to an existing database.
I want to give the project the functionality to create/edit tables/fields and just wondering if people can recommend the best way to do this. I can't use migrations because the project is used on several different servers/databases.
I thought about putting something in the Global.asax file in Application_Start using SqlCommand. Is this a good idea or can you suggest a better way to do this, preferably with EF?
I'm not sure what if any code would be helpful so please let me know if there is anything you would like me to add to the question.
EDIT:
Based on answers so far felt I should also note that I cannot directly access the servers the application is installed on because they belong to clients. Project is deployed locally, zipped and uploaded onto a site for their download.
When using EF Code First, you should use EF Code First Migrations, although you say it's impossible.
Your only reason not to use this is the multiple database servers. Do you use Distributed Transactions?
Otherwise, the only variable is the ConnectionString to the database server, and EF Migrations will do all the work for you to update your SQL schema.
It's probably a bad idea to do this as part of application startup - it'll require that the user that your application connects to the database with has escalated privileges in order to create/edit tables.
You can use migrations to initialise a database as part of a deployment process using the migrate.exe which is part of the EF NuGet package.
It's probably also useful to read a bit more around migrations - there is support for multiple contexts that can each be migrated separately...
Alternatively you could use a SQL script as part of your deployment process but then you'd need to manage the SQL by hand...
I am working on a project which requires me to write several POCO classes using Entity Framework Code First. There is a lot of entity relationships and inheritance going on and its hard to keep track of everything just looking at the code. Now, as we know, Entity Framework Code First yields an .mdf file as your database, and i was thinking for verification, a database diagram would server me better.
Is it possible for me to view my database diagram in this scenario, and how may i do so??
You could always point it to a SQL Server Express database - by default an MVC 4 project uses LocalDB but if you're more comfortable in management studio you can always create your own database and change the connection string to that.
Also from memory I believe you can also attach an mdf file in management studio but may have trouble while the application is running. But I could be thinking of something else there.
I wonder what you are using for updating a client database when your program is patched?
Let's take a look at this scenario:
You have a desktop application (.net, entity framework) which is using sql server compact database.
You release a new version of your application which is using extended database.
The user downloads a patch with modified files
How do you update the database?
I wonder how you are doing this process. I have some conception but I think more experienced people can give me better and tried solutions or advice.
You need a migration framework.
There are existing OSS libraries like FluentMigrator
project page
wiki
long "Getting started" blogpost
Entity Framework Code First will also get its own migration framework, but it's still in beta:
Code First Migrations: Beta 1 Released
Code First Migrations: Beta 1 ‘No-Magic’ Walkthrough
Code First Migrations: Beta 1 ‘With-Magic’ Walkthrough (Automatic Migrations)
You need to provide explicitly or hidden in your code DB upgrade mechanism, and - thus implement something like DB versioning chain
There are a couple of aspects to it.
First is versioning. You need some way of tying teh version of teeh db to the version of the program, could be something as simple as table with a version number in it. You need to check it on executing the application as well.
One fun scenario is you 'update' application and db successfully, and then for some operational reason the customer restores a previous version of the db, or if you are on a frequent patch cycle, do you have to do each patch in order or can thay catch up. Do you want to deal with application only or database only upgrades differently?
There's no one right way for this, you have to look at what sort of changes you make, and what level of complexity you are prepared to maintain in order to cope with everything that could go wrong.
A couple a of things worth looking at.
Two databases, one for static 'read-only' data, and one for more dynamic stuff. Upgrading the static data, can then simply be a restore from a resource within the upgrade package.
The other is how much can you do with meta-data, stored in db tables. For instance a version based xsd to describe your objects instead of a concrete class. That's goes in your read only db, now you've updated code and application with a restore and possibly some transforms.
Lots of ways to go, just remember
'users' will always find some way of making you look like an eejit, by doing something you never thought they would.
The more complex you make the system, the more chance of the above.
And last but not least, don't take short cuts on data version conversions, if you lose data integrity, everything else you do will be wasted.
What are the best practices for database refactoring with codefirst EF4?
I am interested to hear how people change the classes and the database when the RecreateDatabaseIfModelChanges option is not feasible. Migration of data will need to occur.
Currently Microsoft has a solution for doing this with model first:
http://blogs.msdn.com/b/adonet/archive/2010/02/08/entity-designer-database-generation-power-pack.aspx?PageIndex=2#comments
Does anyone have a good strategy for code first?
The EF team have been working on a migrations feature for EF that should solve this problem.
http://blogs.msdn.com/b/efdesign/archive/2010/10/22/code-first-database-evolution-aka-migrations.aspx
Scott Gu said on his recent tour around Europe that they should be releasing this feature soon. I'm holding my breath.
EXCITING UPDATE:
This has now been released as a CTP:
http://blogs.msdn.com/b/adonet/archive/2011/07/27/code-first-migrations-august-2011-ctp-released.aspx
I am working on database context initializer which will notify webmaster if model and db schema are out of sync and will show what differs. This can by useful for developers who prefer to have complete control both over code-first model and database schema. Check it out:
https://github.com/rialib/efextensions
In my CodeFirst application, local builds have a app.config flag that denotes not being in production. When I'm not in production it completely nukes and recreates the database. Since my production database user does NOT have permissions to drop the database even if my web.config transform is missed somehow (thus EF tries to recreate the database) my production database will not be deleted, and instead an exception will be thrown.
My workflow goes like this:
Check out production branch of code with latest changes
Quickly smoke/regression test (this should already be done prior to checking code into the production branch, but just in case)
Download the latest backup of my production database and install it on my local SQLEXPRESS server
Run Open DBDiff between the database my local code created (even though it's production code, since it's local it recreates the database) against the production backup.
Review scripts generated and attempt to run them against the production backup
Assuming no errors occurred, overwrite the database that the code generated with the production backup and do testing against the production data to make sure all data is intact still;
Run scripts on the real production database.
Step #2 automatically creates a new, clean database based on the latest data model so I always know I have an up to date database that doesn't have artifacts from development efforts that may not be production ready yet.