Upgraded our application from .Net Core 3.1 to 5.0.6, and everything was working using an existing database. If I drop the database and run the migrations I get this error:
There is no entity type mapped to the table 'UserClause' used in a data operation. Either add the corresponding entity type to the model or specify the column types in the data operation.
The UserClause table no longer exists it gets renamed in the migration that fails, but if this particular migration completed it would be the Agreement table, but it throws on this migration due to a missing entity type, which definitely doesn't exist either since this was originally run over a year ago.
Anyone know why the migration would be looking for an entity type, and how to resolve the issue? Doesn't seem like this should be checking for entities while it runs the migration.
Looks like in EF Core 5 that some of our migrations where there was a table rename had to have their update or insert statements moved to be after the rename of the table, otherwise you would get this error. Once they were after the table renaming and the table name for the update/insert were changed to the renamed table name everything worked.
In my case, i've to add the schema parameter to the InsertData function, like "dbo"
Related
I have an issue where I have an existing database which where I have mapped over only certain entities to use with EF Core (the DB has 100s of tables and I dont want classes for all of them.
I scaffolded the starting stage like this
dotnet ef dbcontext scaffold .. etc etc
Where I specified specific tables with the connection string.
I then created an initial migration to snapshot the starting stage with
dotnet ef migrations add Initial
I now want to add a new table based on a new entity. So I created a second migration using
dotnet ef migrations add NewTable
But when i run this using..
dotnet ef database update NewTable
It attempts to add the tables in the initial migration! because I havent ran that migration, so I have no records in __EFMigrationsHistory. But I dont want to run the first migration as I already have the tables which were scaffolded! Initial was just to create a snapshot which is what I thought you have to do.
So is there some way to make it think Initial has already been run? By putting something in
__EFMigrationsHistory? Then I can run the NewTable migration without getting "object already exisits".
Thanks
It ran my latest NewTable migration fine after I removed the previous one, otherwise it was still trying to add objects from the initial migration resulting in "Object already exists".
I find this strange as the statement
'dotnet ef database update NewTable'
specifies which migration I wanted to run, and shouldn't run initial again. Anyway this fix worked fine.
One of our dev database got overwritten and couple of stored procedure got missing from it. We don't have any definition of that stored procedure in prod and test. We are planning to restore previous backups and see if we can get the definition for there but before we do that I want to know if there is a way we can get the definition from Entity Framework or from .net code somewhere?
I created a new migration for my asp.net core Web API which applied the changes to my database, But I later deleted the migration manually. I now tried to add a new migration with new changes and but it is giving the error bellow since the changes from the migration I deleted were applied to the database already.
An error occurred while calling method 'BuildWebHost' on class 'Program'. Continuing without the application service provider. Error: There is already an object named 'FK_TaskDates_Tasks_TaskId' in the database.
Could not create constraint or index. See previous errors
Long story short, I'm trying to return the database state back to what it was before the deleted migration was applied.
Is there a way for me to revert the database back to it's working state?
Migrations work by comparing the new migration to the last one run. If there are no prior migrations, it will script out everything in the database.
Generally, for existing database with no prior migrations, you will need to add baseline migration. With EF6 you can use the -IgnoreChanges flag for this baseline. EF Core does not have that (unless recently added), so you can work around it by commenting out the stuff already in the database in the Up() method and applying it. The important thing is that a copy of the model is captured for future comparisons.
Now the next migration you add will only include the changes from that model stored in the code file.
To get your current system working, just comment out the stuff that already exists in the Up() method and keep the changed stuff and apply it (update-database).
I'm working on an ASP.NET 5 app that uses Entity Framework 7 with migrations to alter the application's Microsoft Sql Server database.
I'm running into a few issues when I reach the migrations step, and I would like clarification on what the Entity Framework commands migrations add and database update do.
It's my understanding that
> dnx ef migrations add Initial
creates a C# file ending in the name Initial in a folder named Migrations containing code that will create tables based on the application model classes, and
> dnx ef database update
executes the code that will add those changes to the database. However, after the migrations add command, the database has already been created, and the console gives an error when I run the database update command, saying that the tables already exist.
From what I've read on different tutorials, it seems like migrations add shouldn't actually affect the database, and the changes would take place when you run database update, but it doesn't look like that's the case.
Can someone explain what each of these steps are doing and how they fit together? Thanks in advance!
dnx ef migrations add shouldn't create the database. I suspect DbContext.Database.EnsureCreated() is being called somewhere in your application code giving it this effect.
I've created my objects in ASP.NET MVC4, and after running the application, only UserProfile table is auto created, not the other one corresponding my class.
Followed this advice: Entity Framework 4.1 Code First not creating tables and got this error:
Model compatibility cannot be checked because the database does not contain model metadata. Model compatibility can only be checked for databases created using Code First or Code First Migrations.
Question 1: What is the correct way to do this in Code First approach?
Question 2: Why is the built-in UserProfile created, and not the table for my object? What makes the difference?
Please read my answer here ... same situation I think. UserProfile table created, others not created. My guess is that you've switched to an actual MSSQL DB and not a local DB, but have not pointed your WebSecurity DB initialization to the new database.