I have a problem with generating migration script from existing migration files, via command line, either Script-Migration or dotnet ef migrations script.
The migration file contains the following:
migrationBuilder.DropIndex(
name: "IX_CAR_CAR_ID",
schema: "AUTO",
table: "CARS",
column: "CAR_ID");
The generated SQL script contains SQL that fails during database update.
Expected result:
SQL script should contain schema in the drop index command: DROP INDEX "AUTO"."IX_CAR_CAR_ID"
Actual result:
SQL script does not contain schema in the drop index command: DROP INDEX "IX_CAR_CAR_ID"
I have fixed that by manual modification of the migration file, so instead of migrationBuilder.DropIndex, I use
migrationBuilder.Sql("DROP INDEX \"AUTO\".\"IX_CAR_CAR_ID\"").
Well, that solves the problem for me, but does not remove the cause, I suppose.
I have tried the same with MsSQL server and the result is valid:
DROP INDEX [IX_CAR_CAR_ID] ON [AUTO].[CARS];
so, I assume it might be Oracle only related issue.
Using:
Microsoft.EntityFrameworkCore version 5.0.17
Oracle.EntityFrameworkCore version 5.21.61
My question: does anybony know whether this could be a bug in one of the Oracle or EntityFramework packages?
Related
I am trying to develop an SSIS package that truncates a table in Oracle db. Unfortunately i am getting an error
When i am trying to do select from the truncated table, it works fine - connection manager is setup correctly. I've recreated connection manager just in case but that did help.
Truncated table is in the same schema as the user on which ETL is runned.
Despite an error message, task does it's job. Table get's truncated but error message still appears.
Any ideas what could be the reason?
Regards,
Lukas
2.
Component that i used is Oracle Source task inside of DFT.Oracle source is using a query "TRUNCATE TABLE schema_Name.TableName":
When i use "SELECT * FROM schema_Name.TableName" works fine.
I have the solution.
Instead of using "SQL command" inside of Oracle Source task i used "Execute SQL Task" with the same query. I connected to Oracle db using OLE DB.
I'm seeing flyway seemingly skip migration "V.*" scripts and fail on a later script. Script V1 creates a table, then script V2 alters it. Except that no table gets created, the database is a fresh DB2 instance then it legitimately complains when an alter is attempted.
I have a related question still open, but it would be helpful to get Spring-Boot/Flyway to log the specific SQL that was tried. Not looking for a log of the SQL migration, but the exact SQL in the migration that was attempted.
I tried adding -Dlogging.level.flyway.core.dbsupport.SqlScript=DEBUG but didn't see any change.
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 have an existing database (version x), and I can generate ChangeLog file by using below command
mvn liquibase:generateChangeLog -Dliquibase.outputChangeLogFile=d:\output.xml
After that, I try to remove one table in database directly, How can I user Liquibase to rollback my database to version x ?
Once you have started using Liquibase, you should avoid making changes directly to the database.
Let's simplify the scenario to make it easier to describe. Say at version x your database has a single table called TABLE1 and nothing else. You run the generateChangeLog command, and you get a changelog that has a single changeset that says "create table TABLE1". When Liquibase creates that changeset, it gives it an id. After creating the changelog, you will then want to record in that database that the database and changelog are 'in sync' by running the liquibase changelogSync command - this creates a second table named DATABASECHANGELOG and adds a row to that table with the id of the changeset and some other information.
If you then manually delete the table, Liquibase doesn't 'know' that you have done this, so you would need to also manually let liquibase know that you had done that delete. You would do that by removing the row from the databasechangelog table. You could then re-create the table and get back to version x by running the liquibase update command.
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