![]() When the next person updates, EF won't know what hit it given that the scripts it had run before don't exist. Step 8: Let the rest of your team know how to proceed. Ensure that everything is running then commit the changes. Now, run Update-Database again and watch it execute your new migration script, creating the appropriate tables in the database.īuild, test, run. ![]() 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. This will create practically an empty script. If you had code that hadn't yet had migrations applied to it, this is what I did. Step 6: Confirm EF is ACTUALLY up to date It won't run the Up step with all of the CreateTable commands because it thinks it's already done this. You can run Update-Database again if you want to check that EF thinks its up to date. 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. So, go into the Up method in the Initial migration you just created and comment it all out. So, we need to trick EF into thinking that it's up to date, without running these commands. If you had any seed operations in the previous Configuration.cs, then copy that across.Īt this point, if we ran Update-Database, we'd be getting the original error. This will Create the initial script to create the database from scratch based on the current code. In the Package Manager, run "Enable-Migrations" (EF will prompt you to use -ContextTypeName if you have multiple contexts). I'm assuming you can get this all back from git if necessary. Open your migrations folder and delete it. Open your production database and delete/drop the dbo._MigrationHistory table. In SSMS, Right-Click on the database, Select "Tasks > Export Data-tier application." and follow the prompts. At the same time, we still want those commands to exist so we can create new local databases.įirst, make a backup of your production db. 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. To understand this in more detail, I'd recommend watching both videos referenced here: 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. If it can't, it just tries to apply them in order. When it looks at the Migration Scripts, it tries to reconsile where it was last at with the scripts. 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. Is already an object named '' in the database. 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.Įrror Message: (0x80131904): There And finally, you don't want to delete any production server data. 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. You want to get back to a clean EF environment and then stick to basics, but you can't. How to recover from Entity Framework nightmare - database already has tables with the same nameĭescription: 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. a moderator saw fit to delete my post so I'll paste it here: 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Īpparently. While this question is premised by not caring about the data, sometimes maintenance of the data is essential. Update-Database -TargetMigration:0 -force.Run the normal migration to put it back to current I found this is a great way to roll back your migrations to the original db: UPDATE 11/12/14 - I use this all the time when I make a breaking db change. So create or copy an old one to the correct folder. The mdf does not have to match your old tables, because were going to delete it. You can create a new project and create a new mdf. Create a new MDF and name it the same as the old MDF, put it in the same folder location. ![]() Short answer recreate and delete it properly. To fix the screwed up connections in the project to the MDF. ![]() If you improperly delete the MDF you will have to fix it. I would like to add that Lin's answer is correct.
0 Comments
Leave a Reply. |