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.
Related
I have a database Database named 'DatabaseEF' and another database 'DatabaseOld'.
The former is created in EntityFramework and later is a plain old database created directly in sql server.
Now we have been tasked with merging these 2 but let the old one stay the same way and should not be in EF context because it is also accessed by old ado.net drivers etc.
So how should I go about it?
As for the schema, scaffold (generate entities from existing database, aka. db-first) the old database, combine them into the EF context, and make some fixes if there are something not compatible with the new context or logically incorrect.
As for the existing data on production environment, apply the migration with ef and execute raw sql commands to transfer the data.
I have MS SQL Server 2008 and a program written in C#, using Entity Framework. Without using any third-party tools, can I:
Do daily backup to a file of only certain tables from the database?
Programmatically tell the SQL Server "here is the file with some tables, restore it to the new database A" and then connect to the database A and use the data, if needed, delete the database and load next file?
You could. The daily backup should be done by SQL then you program would be used to locate the backup and restore it to a NEW DB. You can do the backup outside of SQL but not sure why you would need/want to.
Steps would be
- create new empty DB
- restore backup to new empty DB
- fix user permissions on DB (if applicable)
You can overload the constructor of you EF model to take in a connection string that you would make on the fly based on the DB you just reloaded.
As far as ony backing up and restoring some tables you may want to try the following.
Create seperate DB for the "data heavy" items that you do not need to backup and restore as often or that have no value for this process.
Move these items from the current DB to the New DB
Add views in the original DB that have the same exact name as the tables that moved out and pull in a views of the new tables on the second DB
As long as the views are names 100% the same name as the tables that you moved and the view is ONLY on the single table your program should not know the difference but you would now be able to backup the smaller DB and not include all the file and image data. Hope this makes sense
Can try to provide more info if you have a more pointed question
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.
I have started introducing code first migrations in the project, however I have stumbled upon several issues I am not able to resolve.
The setup is, that the project has two targets: an online client, which connects to a WCF service and uses a regular SQL Server database. Also included is an offline client, which holds all data locally and uses a SQL Server CE database.
This already works. Now I need to introduce a way to migrate both database versions. Of course I would prefer using the same migrations code. What I have done so far, is:
enable-migrations (using a localhost SQL Server db, where I create the migrations against)
add-migration (for the initial migration)
One problem is that when I create my SQL Server CE database using CreateIfNotExists initializer, the db will be created with all string properties mapped to nvarchar columns.
However, when I start using migrations, and create my db with a MigrateToLatestVersion initializer, the db will created, but the string properties are now mapped to NTEXT columns.
A subsequent seed fails, because I get the following exception:
The ntext and image data types cannot be used in WHERE, HAVING, GROUP BY, ON, or IN clauses, except when these data types are used with the LIKE or IS NULL predicates.
I have tried to force the model builder to use nvarchar for strings, but to no avail. It is completely ignored.
modelBuilder.Properties<string>().Configure(config => config.HasColumnType("nvarchar"));
I am kind of lost here really.
I have found the solution and it is rather embarrasing, really.
I forgot to recreate my initial migration, after i added my modelbuilder code for the string properties.
I just recreated it now and it works.
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.