I have MVC project which uses EF code first and I'm trying to publish to azure from Visual Studio but I'm receiving error: "Web deploy task failed: data loss might occur". I did some refactoring including renaming columns and I'm aware why the error occurs but I would like to force the migration because I'm sure that I handled the data loss:-) Nevertheless I have no idea how to skip data loss check. I've found that on SQL project you have option in properties that you can uncheck the 'block potential data loose' but I cannot find anything like that on my MVC project. I've tried to include my own script for schema update without the checks for data loss but EF complains that there are pending migrations, so I've tried to copy missing entries to _MigrationHistory table from my development db but it turned out that it's not that simple ;-) Because my app is still in development phase I have reinitialized db but It will be worth to know how to handle that kind of situation on "real" production environment:-)
Edit:
After some testing I've discovered that when publishing to azure there is now option "update database" which by default generates db update script based on diff on the local and azure db. It differs from the old "Run Code First migration" because the the old one was changing Db initializer to MigrateDatabaseToLatestVersion and on application start the db was migrated & seed was run when there were not applied migrations. The "update database" process in other hand is handled only by generated script and the migrations files and MigrationsHistory table is not used on production, neither the seed method. I was confused on the beginning but now it seems logical that update script gives more control over the database change, you always can modify the script, and furthermore the publish process of moving new code to azure performs only after successful db update.
These is an option called AutomaticMigrationDataLossAllowed, set this to true. And run Update-Database -Force. That should do it.
I have got into a bad state with my ASP.Net MVC 5 project, using Code-First Entity Framework. I don't care about losing data, I just want to be able to start fresh, recreate the database and start using Code-First migrations.
Currently I am in a state where every attempt to Update-Database results in an exception being thrown or getting an error message. Also the website can't access the database correctly. How can I wipe all migrations, re-create the database and start from scratch without having to create a new project? In other words, I want to keep my code but drop the database.
Later I will also want to get the deployment database (SQL Server on Azure) in sync. Again, I don't mind dropping all the data - I just want to get it working.
Please provide any how-to steps to get back to a clean state. Much appreciated.
Follow below steps:
1) First go to Server Explorer in Visual Studio, check if the ".mdf" Data Connections for this project are connected, if so, right click and delete.
2 )Go to Solution Explorer, click show All Files icon.
3) Go to App_Data, right click and delete all ".mdf" files for this project.
4) Delete Migrations folder by right click and delete.
5) Go to SQL Server Management Studio, make sure the DB for this project is not there, otherwise delete it.
6) Go to Package Manager Console in Visual Studio and type:
Enable-Migrations -Force
Add-Migration init
Update-Database
7) Run your application
Note: In step 6 part 3, if you get an error "Cannot attach the file...", it is possibly because you didn't delete the database files completely in SQL Server.
I would like to add that Lin's answer is correct.
If you improperly delete the MDF you will have to fix it. To fix the screwed up connections in the project to the MDF. Short answer; recreate and delete it properly.
Create a new MDF and name it the same as the old MDF, put it in the same folder location. You can create a new project and create a new mdf. The mdf does not have to match your old tables, because were going to delete it. So create or copy an old one to the correct folder.
Open it in server explorer [double click the mdf from solution explorer]
Delete it in server explorer
Delete it from solution explorer
run update-database -force [Use force if necessary]
Done, enjoy your new db
UPDATE 11/12/14 - I use this all the time when I make a breaking db change.
I found this is a great way to roll back your migrations to the original db:
Puts the db back to original
Run the normal migration to put it back to current
Update-Database -TargetMigration:0 -force [This will destroy all tables and all data.]
Update-Database -force [use force if necessary]
This worked for me:
Delete database from SQL Server Object Explorer in Visual Studio.
Right-click and select delete.
Delete mdf and ldf files from file system - if they are still there.
Rebuild Solution.
Start Application - database will be re-created.
While this question is premised by not caring about the data, sometimes maintenance of the data is essential.
If so, I wrote a list of steps on how to recover from Entity Framework nightmare when the database already has tables with the same name here: How to recover from Entity Framework nightmare - database already has tables with the same name
Apparently... a moderator saw fit to delete my post so I'll paste it here:
How to recover from Entity Framework nightmare - database already has tables with the same name
Description: If you're like us when your team is new to EF, you'll end up in a state where you either can't create a new local database or you can't apply updates to your production database. You want to get back to a clean EF environment and then stick to basics, but you can't. If you get it working for production, you can't create a local db, and if you get it working for local, your production server gets out of sync. And finally, you don't want to delete any production server data.
Symptom: Can't run Update-Database because it's trying to run the creation script and the database already has tables with the same name.
Error Message: System.Data.SqlClient.SqlException (0x80131904): There
is already an object named '' in the database.
Problem Background: EF understands where the current database is at compared to where the code is at based on a table in the database called dbo.__MigrationHistory. When it looks at the Migration Scripts, it tries to reconsile where it was last at with the scripts. If it can't, it just tries to apply them in order. This means, it goes back to the initial creation script and if you look at the very first part in the UP command, it'll be the CreeateTable for the table that the error was occurring on.
To understand this in more detail, I'd recommend watching both videos referenced here:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
Solution: What we need to do is to trick EF into thinking that the current database is up to date while not applying these CreateTable commands. At the same time, we still want those commands to exist so we can create new local databases.
Step 1: Production DB clean
First, make a backup of your production db. In SSMS, Right-Click on the database, Select "Tasks > Export Data-tier application..." and follow the prompts.
Open your production database and delete/drop the dbo.__MigrationHistory table.
Step 2: Local environment clean
Open your migrations folder and delete it. I'm assuming you can get this all back from git if necessary.
Step 3: Recreate Initial
In the Package Manager, run "Enable-Migrations" (EF will prompt you to use -ContextTypeName if you have multiple contexts).
Run "Add-Migration Initial -verbose". This will Create the initial script to create the database from scratch based on the current code.
If you had any seed operations in the previous Configuration.cs, then copy that across.
Step 4: Trick EF
At this point, if we ran Update-Database, we'd be getting the original error. So, we need to trick EF into thinking that it's up to date, without running these commands. So, go into the Up method in the Initial migration you just created and comment it all out.
Step 5: Update-Database
With no code to execute on the Up process, EF will create the dbo.__MigrationHistory table with the correct entry to say that it ran this script correctly. Go and check it out if you like.
Now, uncomment that code and save.
You can run Update-Database again if you want to check that EF thinks its up to date. It won't run the Up step with all of the CreateTable commands because it thinks it's already done this.
Step 6: Confirm EF is ACTUALLY up to date
If you had code that hadn't yet had migrations applied to it, this is what I did...
Run "Add-Migration MissingMigrations"
This will create practically an empty script. Because the code was there already, there was actually the correct commands to create these tables in the initial migration script, so I just cut the CreateTable and equivalent drop commands into the Up and Down methods.
Now, run Update-Database again and watch it execute your new migration script, creating the appropriate tables in the database.
Step 7: Re-confirm and commit.
Build, test, run. Ensure that everything is running then commit the changes.
Step 8: Let the rest of your team know how to proceed.
When the next person updates, EF won't know what hit it given that the scripts it had run before don't exist. But, assuming that local databases can be blown away and re-created, this is all good. They will need to drop their local database and add create it from EF again. If they had local changes and pending migrations, I'd recommend they create their DB again on master, switch to their feature branch and re-create those migration scripts from scratch.
Just want to add to the excellent answer of #Lin:
5) B.
If you don't have SQL Management Studio, go to "SQL Server Object Explorer".
If you cannot see your project db in the localdb "SQL Server Object Explorer", then click on "Add SQL server" button to add it to the list manually. Then you can delete the db from the list.
A possible very simple fix that worked for me. After deleting any database references and connections you find in server/serverobject explorer, right click the App_Data folder (didn't show any objects within the application for me) and select open. Once open put all the database/etc. files in a backup folder or if you have the guts just delete them. Run your application and it should recreate everything from scratch.
My solution is best suited for :
- deleted your mdf file
- want to re-create your db.
In order to recreate your database you need add the connection using Visual Studio.
Step 1 : Go to Server Explorer add new connection( or look for a add db icon).
Step 2 : Change Datasource to Microsoft SQL Server Database File.
Step 3 : add any database name you desire in the Database file name field.(preferably the same name you have in the web.config AttachDbFilename attribute)
Step 4 : click browse and navigate to where you will like it to be located.
Step 5 : in the package manager console run command update-database
Built an app locally with an EF code-first database - not sure how to upload it to a shared hosting environment such as GoDaddy. It makes sense that something would be amiss because on the shared hosting your code can't just go create a database, but on the flip side I can't find anything to copy the CREATE sql and create it on the server like you would with MySQL
Feel a little silly because I've been using .NET for over a year now but at work the databases are already set up and we have full control over our environments.
If the database has no data that you need to preserve the easiest method is just to install the app on the new host and set the connection string to your new database on the host. On the first attempt to load a page accessing the database, the database will automatically be created (note that you need to load a page which hits the database - sometimes the home page is not sufficient).
This method is a lot more straightforward than generating SQL and then executing it on the production database.
If there is data that you need to preserve then the best method will be taking a backup and installing the backup on the host. In SSMS simply right-click the database in the left pane, then Tools > Backup... To restore on the server connect to the server in SSMS and right-click the 'Database' node in the left panel and select 'Restore Database...' I'm not sure if the host provides a direct connection from SSMS but they should at a minimum have a mechanism to restore a .bak file.
Going forward you should ensure that you can execute SQL on your database as a very convenient method for deploying EF Migrations is to generate the SQL update script on the development server and then deploy this by executing it in production.
Depending on your web host, you may be able to restore the database. If this is an option, simply back up your database on your local machine and restore it on the server via the management console.
You can back up your local database using SQL Server Management Console. This works well even for larger databases as you can directly restore all your data, your schema, etc.
I've had experience with three different hosts so far and all of them have this as an option. You'll usually find this under the Database tab for the web site. The rest from there is up to you because it's usually different across the various hosts.
We're considering using EF 4.3.1 code-based migrations, but aren't clear about how to integrate Migrations with our present dev/deployment methodology...
The app in-question is a desktop WPF app, with each desktop having its own SQL Server instance (each with 4 separate databases). It is deployed into a "field" environment with zero local IT support. Any database migration must be done using SQL scripts executed by the installer (probably InstallShield). There will not be anyone available who can run a command at a PMC prompt to upgrade the db when it is deployed/upgraded at a field location. Thus the ultimate "output" from EF Migrations must be a set of SQL scripts, which the installer will selectively apply.
Also, we have multiple developers making concurrent database changes.. there is NO DBA. Each developer simply checks-in their code (model) changes to TFS, and the next time they do get-latest, the changes to the model automatically cause a new database to be created on their dev system. So how can we now have each developer perform their own local migrations (rather than deleting/recreating their local databases), and then manage/consolidate/combine those migrations? And what about collisions?
During dev and unit-testing, each developer may delete their (entire) local database multiple times during a single checkout/checkin iteration. This works great with Code First, since the database gets automatically rebuilt when the app is restarted. But this means that the _MigrationHistory table in the database also gets deleted. How do we handle this? Don't we need the migration history of each dev system? If not, then where/how do we detect the aggregate changes which need to be applied to the delivered system?
I can see the value of using Migrations to deal with the mechanics of migrating a database, but what's not clear is how to take advantage of it without introducing a centralized database "change-control" bottleneck into the dev cycle, and thus losing one of the key benefits of Code First.
Any insight/advice would be greatly appreciated!
DadCat
I know this is an old question but I thought I'd post some of my experiences with EF Migrations (v6.1).
Each dev will be fine. Migrations are put into classes with a timestamp in the name, so no collisions will happen. The DB on the dev's machine will be updated after doing a get latest and running the app (or the update-database command).
Deleting the local db and recreating is fine. Just make sure the dev runs update-database before adding additional migrations or things will get out of sync. I'm a bit confused as to why they'd need to delete the local DB, but that's out of scope. You may find that your process needs to change to accommodate EF Migrations.
I can't help you with the installer question, as a similar question brought me here. The update-database command does have a -script option that will generate the proper change script, but I'm unclear how to automate that on a build server.
I've created a locally attached SQL Server 2008 Express for an ASP.NET MVC application (in App_Data), but I need to access the built-in users table for relationships to custom models that I'm creating. Since the database is local, it doesn't show up when I run aspnet_regsql.exe. Is there a way around this, or should I be setting up the database as a true SQL Server database and providing scripts to generate the tables?
I'm trying to get an environment configured so anyone who checks out the code will have the database automatically, instead of having to spend time configuring it before they can write any code (basically a situation like Rails has where you can have somebody new check out the code, and maybe with some minor configuration type rake db:create and rake db:migrate and have the entire working environment set up.
I'd recommend using a SQL Server database and you can then use aspnet_regsql.exe to generate the schema for you.
If the membership provider is working make sure you have selected 'Show all files' in solution explorer and check the App_Data folder. The DB will probably be called something like ASPNETDB.MDF. ASP.NET / VS has a habbit of setting this database up for you and trying to hide it.