I am using Code First, and I want to migrate it to ORACLE database, after multiple migrations process, I am getting this error,
The best overloaded method match for Oracle.ManagedDataAccess.EntityFramework.OracleMigrationSqlGenerator.Generate(System.Data.Entity.Migrations.Model.CreateTableOperation) has some invalid arguments
I'm facing the same problem
finally I solve it by opening the database and delete the migration_history table manually
and run the command again.
see at EF5 Code First - Changing A Column Type With Migrations
in each migration you will save a record in __MigrationHistory, so in case there is no sync between the code and the migration do the following:
delete the migration history table in the database.
migrate it again by create new migration 'in package manager console' add-migration data.
update the migration to database update-database
Related
I am trying to build an api in beego. I have to make a controller and a model for this project. Model has a database table but the table is not in my database. Beego automatically creates the table in the database. How can I stop it.
I imagine you are using this command err := orm.RunSyncdb(name, force, verbose). This command looks for changes in your models and if there are any drops the database and creates a new one. If you want to stop it simply don't use this command and write database migrations for your app with bee generate migration migration_name. In the file you have to run the required sql to create the tables. After writing your migrations run bee migrate -conn="{your_database_connection_string}".
I created few migrations and migrated them, after that I deleted them manually without rolling back.
and now I want to rollback other migrations but I'm getting an error that migration not found referring to the last migration I had deleted, even when I rollback a specefic migration with a --path I still get
migration not found: name_of_the_last_migration_I deleted_manually
with referring the last migration I deleted manually.
The migrations are stored to a table (called "migrations") in your database. When you run a migration, it is added to that table - using the rollback function looks at the latest migration in the table and runs the down() function for it.
If you reverse a migration manually (ie. deleting the table or columns that the migration created) but then try to use the rollback function, it will fail because the migration cannot remove columns / tables that have already been removed.
So the answer is to delete the migration(s) that you have reversed from the migrations table.
I am trying to replace sql server with sqlite as database in aspnetboilerplate following this tutorial. we have to remove previous migrations and add new one before running "update-database" but it gives empty database and running this project gives error " 'SQLite Error 1: 'no such table: AbpEditions". how to populate newly installed sqlite database?
there are SeedHelper.cs and initialHostDbBuilder.cs files in EntityFrameworkCore project, probably for seeding database but i could not figure out how to use them?
Make sure that config files in all of your projects that need the access to the database are pointing to the same file. If you have just used the value from the article
"Default": "Data Source=SqliteDemoDb.db"
then you have a separate database file in each project. The file that the migrations are executed on is in the EntityFramework project.
I am having a very bad situation here, working on a Laravel 5 project. previously developed by another developer. That developer at start created couple of tables using migration generators and added some columns using migrations. After that, he added table columns straight away using some sql GUI. I was given the sql dump which i imported and set it up on my local machine, now when i created a table using php artisan make:migration create_myTableName_table --create="myTableName" the table migration is created successfully, but, when i did php artisan migrate it's giving me SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'someTable' already exists I checked migrations folder and matched it with current version of someTable and i can see the columns are different, same with other tables aswell.
What should be the best case to handle this in this situation, i want to keep up with Laravel migrations generator so that in future if any other developer want to work on this project he just has to run migration command to migrate database or to create tables or create columns... Should i re-write all migrations ? pleas help. Thanks
Given your situation, I’d put the .sql export in your repository, clear out the old, broken migrations, and create a new one that initially imports the database dump. Then just create migrations as normal going forward.
Quick and dirty?
Delete current migration files. Clear your migrations table and export the whole DB. Put the SQL dump in the repo and instruct other devs to import it before they run php artisan migrate. With the dump imported and migrations table truncated, you can create new migrations with no further collisions with the legacy migrations.
Feeling ambitious?
Use a package like migrations-generator to generate migrations based on your current DB structure. Then, migrate away.
I have a local instance of a database that I recently created using DbContext.Database.Create(), so the __MigrationHistory table exists with an InitalCreate entry that matches the code at the moment.
Some code-based migrations exist in the Migrations folder, however. These will be run in our development and staging environments to bring those databases in line with the code. I don't need to apply them locally, however, since I created the database using the current code.
I now need to make a change to the model and create the corresponding migration. But when I run Add-Migration TestMigration, I get the following error
Unable to generate an explicit migration because the following explicit
migrations are pending:
[201203271113060_AddTableX,
201203290856574_AlterColumnY]
Apply the pending explicit migrations before attempting to generate
a new explicit migration.
What should I do in this case? I can't point the Add-Migration tool at another environment because it's not guaranteed that version matches what I have locally. I want a migration that matches only the changes I've made.
It seems I have a few options but none are ideal:
Delete the other migrations from the Migrations folder, run the Add-Migration command, upgrade the database, then restore the old migrations. This is simple but seems a bit hackish.
Revert to the version of the model in source control that the first migration was applied to, then build this and use it to create the database. Then get the latest version, apply all the migrations, then I'm ready to add my migration. This seems like a lot of effort!
Create the migration manually.
Does anyone have any suggestions about how to manage this?
We are planning to use a variant of your Option #1...
Our Standard Operating Procedure is to generate a SQL script for each migration (using the -script option of update-database), in order to have SQL scripts to be applied to end-user "production" databases by InstallShield (we plan to use EF update-database only for developer databases).
Thus, we have both the Migration .cs files and the corresponding .sql files for all migrations in our Migrations folder.
So rather than deleting the migrations from the Migrations folder (as you proposed in #1), we use SQL Mgmt Studio to manually apply just the parts of the .sql files that do the inserts into _MigrationHistory.
That brings the _MigrationHistory of the local database up-to-date with the changes that are already incorporated into that database.
But it's a kludge, and we're still looking for a better solution.
DadCat
What I've found works best is very simple: don't use DbContext.Database.Create() once you've enabled migrations. If you want to programmatically create a new database, use the migrations API instead.
var migrator = new DbMigrator(new Configuration());
migrator.Update();
Then you've got the full migration history and adding further migrations works just as expected.
You either need to run "update-database" from the package manager console to push your changes to the database OR you can delete the pending migration file ([201203271113060_AddTableX]) from your Migrations folder and then re-run "add-migration" to create a brand new migration based off of your edits.
I have encountered the same problem.
If you run
Update-database
and then run
Add-Migration YourMigrationName
This solves the problem
simply exclude the old migration file from the solution files.