I Use code-first migration but I has error when run application.
error:Cannot find the object "dbo.Products" because it does not exist or you do not have permissions.
I have already got deleted Products table manually on sql server.I expect when Re-Run Project All table recreate if not exist in sql server.
In addition,I write 2 line for configure migration.
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
any help ?
If you are using migrations you shouldn't "manually" change the database. So now EF is generating code to remove the table for you, but it doesn't exist. Solution is to comment out the code in the Up() method that removes the table and update-database. See https://msdn.microsoft.com/en-US/data/dn481501
If you want your database recreated, you will need to switch to an initializer such as DropCreateDatabaseIfModelChanges. See http://www.entityframeworktutorial.net/code-first/database-initialization-strategy-in-code-first.aspx.
Related
I'm setting up EF Core 3.1.3 migrations against an existing SQL Server database.
This is what I've done so far:
Scaffold my model from the existing database.
Add the InitialCreate migration.
Remove the contents of the Up() method in InitialCreate.
Update database to create the __EFMigrationsHistory table.
Then I added a property to an entity class and ran dotnet ef add migration.
Now looking at the BuildTargetModel method of the second migration I see that it contains pretty much the same code as MyDbContextModelSnapshot.BuildModel. I.e. it lists all entities and all their properties and relationships.
What does BuildTargetModel on a migration do? Why does it have to duplicate most of the snapshot code? I would only expect to find the diff in a migration.
As confirmed by the developers of EF Core, this behaviour is by design:
https://github.com/dotnet/EntityFramework.Docs/issues/2288
I have an app and it has a database behind it. This app is deployed in multiple instances, where each instance has different version of code and database. By different version, I mean it might be slightly older version of code and database.
What I would like to do is:
Start using EF6 database migrations on the development version.
In correct order (dev->stage->prod), deploy to other instances the development version and update the database using EF6 database migrations.
Create new instance of app, using EF6 database migrations.
The question I am running into is this:
I understand that I can enable migrations on my development instance, then do Add-Migration Initial –IgnoreChanges and create incremental migrations for new database changes. As other environments will be updated, these changes will be applied (running Update-Database during deployment).
However, my question is, with this kind of setup, how to handle when I have to spin up a new instance of the app? I need a migration which would create all the tables. I know how to create this migration also: by pointing the connecting string to empty database and running Add-Migration. However, when I will deploy my code to existing instances and run Update-Database, EF will try to run this baseline migration and crash.
How to handle these two scenarios in a simple and automated way?
I guess I am imagining two types of migrations:
Update-Database -Baseline-And-Incremental
and
Update-Database -Incremental
Also, this will all be automated, so I dont want to run Update-Database and pass in the non-baseline migration names to run on existing database during deployment.
1st
In your DbContext constructor add
Database.SetInitializer(new CreateDatabaseIfNotExists<MPContext>()); //Create database if not existed
Database.SetInitializer(new MigrateDatabaseToLatestVersion<yourContext, Configuration>()); // uses the configuration for migrations for this DbContext
and your configuration class should look like this:
internal sealed class Configuration : DbMigrationsConfiguration<DBO.MPContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
}
}
AutomaticMigrationsEnabled = true; // enables automatic migrations
AutomaticMigrationDataLossAllowed = true;
//this kinda gives permision to delete a table, what I mean is say you have a one to
//many relation in a table and you decide to remove it for any reason by adding this
//code you allow the migration to delete the reference (Sorry for the bad english)
public class TEST{
public List<TEST2> test2 {get;set;}
}
if you decide to remove test from test it deletes the reference from TEST class (thereore you lose that data)
P.S if you are using an online DB you might need to add Persist Security Info=True to your connection string
Hope this helps
I am learning entity framework. I am reading through some tutorials about initialization and how there are
CreateDatabaseIfNotExists
DropCreateDatabaseIfModelChanges
DropCreateDatabaseAlways
Custom DB Initializer
to choose from.
This makes me wonder, what does one do when they want to change the schema, but they want to keep the data they have?
I was just using sql directly, I could make temp tables, move stuff over, recreate the table with new columnns, move stuff back, etcv
What do you do when your classes and/or their relationships change in EF?
I think your looking for EF migrations:
https://learn.microsoft.com/en-us/ef/ef6/modeling/code-first/migrations/
for every schema change you create a migration, where you can add or remove tables or columns, or you can even run your custom script.
Each migration has an Up method, these will be applied if you run your migration, and a Down method this is used if you want to roll back to the previous migration for some reason.
With Update-Database you can apply all migrations, and with Update-Database –TargetMigration:{nameOfMigration} you can migrate to a specific version.
I want Update database by code first migration .for example I have 3 entity in contex and 1 table in database and there is a problem when I run program and get this error:There is already table.
Migration Configuration
internal sealed class Configuration : DbMigrationsConfiguration<ApplicationDbContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
// AutomaticMigrationDataLossAllowed = false;
}
protected override void Seed(ApplicationDbContext context)
{
// This method will be called after migrating to the latest version.
}
}
IdentityModel
public ApplicationDbContext() : base("DefaultConnection" )
{
Database.SetInitializer<ApplicationDbContext>(new MigrateDatabaseToLatestVersion<ApplicationDbContext, Migrations.Configuration>());
}
any help ?
Have you tried to use the Add-Migration "migration_name" before calling update database? Or maybe try to use Update-Database -Force.
Otherwise, I have found some steps that maybe could be useful:
Remove the existing Migrations folder in your project, and DROP the table __MigrationHistory from the existing database.
Run the enable-migrations command from the Package Manager Console.
Run the add-migration command to create an initial migration.
Remove all of the code in Up() method for the initial migration.
Run the update-database command to apply the initial migration to your database. This doesn't make any changes to existing objects (because the Up() method contains no code), but it marks the existing database as having been migrated to the initial state.
Make changes to your code-first model.
Run the add-migration command to create a new migration. The code in the Up() method of the new migration will contain only the changes to your object model.
Run the update-database command to apply the changes to your database.
That's a common problem with migrations. When you add a new migration it compares the current code model to the prior code model stored in the prior migration. If this is the first migration it will thus generate code for everything, so sometimes the code will try to add objects that already exist.
To get past this, you can comment out the code in the Up() method of the migration for the items that already exist and then apply the migration (update-database). Now it will correctly generate just the changes moving forward.
To prevent this, you should always generate an initial snapshot of your database without generating any changes:
add-migration MyStartingPoint -IgnoreChanges // ignorechanges flag tells EF to just take snapshot with no code in Up()
Here is a document on how migrations operate "under the hood".
I am adding Code First migrations to an existing Entity Framework 6 domain with existing databases. I need the following behaviour:
If the database exists, insert the InitialCreate migration but do not perform the contents of the migration Up().
If the database does not exist, create it and run the contents of Up() and Down() to create an empty but correct-schema database.
I need (1) for when I release through the Continuous Delivery deployment. I need (2) for when a developer is cleaning down their machine and starting fresh. I do not want to use automatic migrations.
I appreciate that a Migration has no concept of the Database Context, it's only responsible for generating a series of SQL instructions.
Are these my only options?
1. Move contents of Up and Down out of InitialCreate and into Configuration.Seed
The InitialCreate migration runs Up() but no changes are made. In Seed() we have access to DbContext, so we can work out if the tables exist and create them if needed.
I think this might break when there are lots of migrations to run as Seed() is called after the migrations. On an empty database, the creation of the tables would be happening after updates to those schemas.
2. Perform the Up() method as a SQL Script
Migrations allows the developer to put inline SQL into Up() and Down(). Move the creation of the database into inline SQL and add a IF NOT EXISTS at the top.
I don't like this because you lose the use of the model that is supplied with the InitialCreate. If the model is updated, the fixed SQL string won't.
3. Empty out the Up() and Down() methods, do a release, put the creation code back in, do another release
When the InitialCreate migration is run first time, it won't have anything in it. The entry will go into the migrations database without running anything.
Once that first release has been performed, I can then put the creation code back in so that when future developers run it without a database, it will create properly.
Note: This one is my current favourite as it uses Entity Framework as designed and I can personally control adding the code back in after a release.
Is there a better way?
Edit
I am unable to build the database from empty, this might be something to do with the Context model creation. It uses a bespoke pluggable method:
public MyObjectContext()
{
((IObjectContextAdapter) this).ObjectContext.ContextOptions.LazyLoadingEnabled = true;
((IObjectContextAdapter)this).ObjectContext.CommandTimeout = 180;
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
System.Type configType = typeof(AnswerMap); //any of your configuration classes here
var typesToRegister = Assembly.GetAssembly(configType).GetTypes()
.Where(type => !String.IsNullOrEmpty(type.Namespace))
.Where(type => type.BaseType != null && type.BaseType.IsGenericType && type.BaseType.GetGenericTypeDefinition() == typeof(EntityTypeConfiguration<>));
foreach (var type in typesToRegister)
{
dynamic configurationInstance = Activator.CreateInstance(type);
modelBuilder.Configurations.Add(configurationInstance);
}
base.OnModelCreating(modelBuilder);
}
All the map objects are in the same DLL, the domain entities used for the database tables are in a separate DLL.
This is what we do:
1) Create an initial migration that is a snapshot of the current database. Use -IgnoreChanges to keep any code out of the Up(). You don't need the Up() code because EF will compare the prior model (blank) to the one stored in the migration and realize you need to add all the existing objects at the time of the snapshot.
add-migration Initial -IgnoreChanges
2) Add new migrations as you develop. In a team environment you could run into the issues outlined here: https://msdn.microsoft.com/en-US/data/dn481501
3) You can generate an idempotent script that will rebuild an entire system from scratch and apply any (or all) migrations.
Update-Database -Script -SourceMigration $InitialDatabase
https://msdn.microsoft.com/en-us/data/jj591621.aspx?f=255&MSPPError=-2147217396#idempotent