Please help me understand this.
I have two .net servers:
-Production
-Staging
Whenever I add a new table fields to my existing DB, I have to do code first migration, I also have to add this new field to the class type in my model.cs, then I have to ask my Network admin to run the sql queries to alter table, all of this is on Staging.
Now I am ready to move to production, so I ask my network administrator to alter tables in production, and i was waiting for the site to go down as the files in
wwwroot/productionfiles
doesn't have my new changes with respect to code first migration, but the site didn't do down, the site works.
I am confused, I thought I need to follow the same steps for production as I have always followed in staging?
why did my production server worked only with an "alter table" for the database
yet my staging server always requires me to run "alter table..." for the database, then run code first migration in my code???
help me understand.
The Code First Migration is needed for the staging server DB to be in sync with the expected Entity Framework schema version.
In production maybe the schema version validation is skipped.
What matters in the end is that DB schema is consistent with the EF model, regardless on how that migration was made.
Related
I have an ASP.NET MVC application that uses EF migrations. Usually when I make changes to the model in local development, I create new migration, and then to apply the changes in production I generate a script with the modifications and apply it to the production server db.
I have been doing this for months, and apparently it worked ok, so I assumed that both databases were synced (i.e. the migrationHistory table was the same in both databases).
But now I have just realised that the contents of the __MigrationHistory table are different in local and server: in local there is one migration that does not exist in server (note: its not the last migration, its one from months ago). So let's say in local I have these migrations applied (as shown in migrationHistory table):
migration 1
migration 2
migration 3
migration 4
but in server, I don't have migration 2.
I don't understand how this happened: I though EF would not allow this and it should have throw an error when I tried to apply migration 3 in server, but apparently it did not...
So the question is: how can I fix this now?
My first idea is to
modify local model to remove the changes on the offending migration
delete migration file
delete local database
recreate local database with update-database
re-do changes to the model
create new migration
update db to apply new migration
generate script with the changes and apply it to the production db
If I am right, with this both databases will be synced? Or what would be the correct way to fix all this?
I'm using MVC 5 with Entity Framework 6, automatic migrations are disabled, no seed is used and I'm scripting out my updates to production.
I'll hold up my hands and say I'm fairly new to MVC and EF.
I just uploaded a new codebase to production, and forgot that the model had changed. When I went to login to the new version, it threw and error page. Fine, I forgot to script the latest migration - I did that, hooked up to SSMS and found that the database was gone.
Slight panic, restore from backup (I'm not that daft!) and apply the migration and everything starts working as it should.
Why did my code delete the entire database when the model had changed? As said, automatic migrations are disabled and this behaviour doesn't happen on development machines, they throw an error about the model having been changed.
Edit to add: Whilst looking at the Initialisation patterns in Fernanda's answer, none of them say "Drop the database and then do nothing else". My database was dropped, the MDF and LDF gone, nothing is SSMS and nothing recreated in its place. If a blank database was created in its place I'd understand a bit more. That said, the user account had DBO on the database but not master, so would have been able to drop the database but not create a new one?
Read this about Database Initialization Strategies in Code-First:
http://www.entityframeworktutorial.net/code-first/database-initialization-strategy-in-code-first.aspx
Check your dbcontext initialization and be sure that the option DropCreateDatabaseIfModelChanges is comment
//Database.SetInitializer(new DropCreateDatabaseIfModelChanges());
I am working on a project which is using Entity Framework code first for its data structure. It was created with code first, but was never migrated again and only has its initial migration data stored. Since then, the database has been modified directly through server explorer in VS2015.
There is no migration information about any changes and the database has critical information which I cannot lose.
Which brings me to my Questions.
If I create a new migration and update the database from it, will it wipe all changes which were not recorded in migrations and still leave the changes which were made as well?
The details of your question is a bit sketchy, but I will make some assumptions in order to help you along. Please correct where I am wrong.
I assume that you want to keep the data which resulted from the changes which were effected directly to the database, but you do not want to keep the changes that was effected to the database - in other words: keep the data but not the datastructures.
My advice is as follows
Always perform a full backup of your database when you are about to do something you are uncertain about.
If you can identify the tables you want to update, you can always use the SELECT INTO statement to create a quick backup of the specific tables only. These tables will not be removed when you do a EF database migration unless you explicitly script the deletion.
You can build the SELECT INTO statement into your EF migration via the Sql() method, or you can manually run the command against the database.
More information:
Click here to learn about EF code first migrations in general
Click here for a comprehensive code first migration reference
I believe following two posts will help you.
EF 4.3 Migration Walkthrough : http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
update:
Code First Migrations with an existing database
https://msdn.microsoft.com/en-us/data/dn579398.aspx
I have inherited an entity framework application that i have been tasked to create within a separate environment with a completely separated database as well on a new db server. Seems easy enough. I backup the database from the original and restore it on the new database server. the data is the exact same at this point.
For testing purposes i change the local connection string to the new database server and run my web app locally. I get an error in the browser that is "MySql.Data.MySqlClient.MySqlException: Can't write; duplicate key in table '#sql-3b87_2d5f91'" i dont even have a table with that name and have no idea where it comes from. entity framework also creates duplicate tables for all of my tables except for migrations table.
I have tried other things as well, after restoring the db in the new db server to the original again, i have tried running 'update-database' and the same issues happen.
Now if i disregard restoring the new database with the backup from the original and run "update-database" on the new database server. it creates the schema correctly, but it lacks the data i need for testing.
Any ideas why this may be happening? i would like to avoid writing a sql script to transfer data.
I am using MVC 5 with NET Framework 4.5.1. with Code-first. I am also using Migrations with the SQL 2012 server and (localdb)\v11.0.
I am in the middle of developing a project using C# and MVC5. During development, I created a lot of new tables in my developmental computer and changed a the "Name" field which I believe the system makes an index for. I added it and deleted it several times.
After that, I added a lot iof new unrelated tables, but for some reason, my migrations started giving me foreign constraint errors due to the indexes for the "Name" field. These errors kept multiplying as I fixed them, so, I decided to revert back to an initial state in the migration, and reset using the current position as a new starting point. I was hoping, that the production table would look at this new starting point in the development db, and resynch itself to the developmental state. I thought that I had read somewhere that the production db matches itself to the developmental db and updates itself. I believe that there is a migration file in the production db which would match itself to the file in the developmental db -that file was clearly out of synch. I have considered deleting the data in it, but I am holding off till I get advice.
Anyway, I changed the name of the migrations directory in the Dev computer and excluded it from the project. Then I reinitialized my tables (using a new db name in my local db) on the dev computer and re-loaded it with the initialization data. It all worked.
Now, I had a new problem, my production db and my developmental db were different, and my migration in the dev computer was setup to create new files whereas the one in the production state was expecting the older migration. Every time I tried to update the production db using the development computer, I kept getting an error that the files existed - which of course they did.
So, I commented out all the create files in my migration file and re-tried. Now, the production db would start, but would not run because the updated code had new fields it was referring to which did not get created in the production db. So, on my production db I started to get errors of all the fields that were missing. I tried to make automatic migrations true as well, that did not work. I am guessing, the only way to fix this is to go in manually and synch the fields one by one.
QUESTION 1: Is there an automatic way to synch (using migrations) the production db and the developmental db so that they become the same same as the developmental db?
QUESTION 2: Keeping in view the above scenario, what would have been a better way to go about to re-set the miggrations with a production db out as well?
I found a solution. The folks at Red-Gate have a great SQL tool called the SQL Compare. It compares the database file structures and even makes them EXACTLY the same, at a click of a button.
But, before you use it, be sure you ONLY compare "tables", as opposed to everything which includes "users" and "roles" and a lot more. That is because when you run the software, it backups, deletes and re-creates, and if the roles or users get deleted, the software can no longer access the database and everything gets deleted! Also... MAKE A BACKUP! (I lost all my test data on my first try)
http://www.red-gate.com/products/sql-development/sql-compare/
(This is not a sales plug for the folks at Red-Gate. I dont know them, but their tool helped me immensely - its a good tool, easy to use, and FREE for 14 days! - and I list it here so that anyone else, and I am sure there are many, who may be stuck like me can be helped.)
April 24 2015
Ok. There is more to it after you synch both the databases so that they look exactly alike.
Create a Back up of your production data *
Delete the Migration folder in your developmental folder.
Enable Migrations again
Add an initial migration
Update the local database
Now you have your local completely set up *
Go to the host database
Find the table called "__MigrationHistory" in Host/Production
Delete all the data (you want to purge it) ("__MigrationHistory" (Host))
Now copy all the data from the local "__MigrationHistory" to the hosted "__MigrationHistory"
(There will be your one single line i.e. the initial one you created above")
Now the data has been saved and every thing will be synched and it will work.
You can begin development again.