CoreFirst EFMigrationsHistory Error

[l2999019]

I copied this code to execute corefirst and told me that the table did not exist.

I am a brand new database

Error:
Failed executing DbCommand (113ms) [Parameters=[], CommandType='Text', CommandTimeout='0']
SELECT "MigrationId", "ProductVersion"
FROM "__EFMigrationsHistory"
ORDER BY "MigrationId"

What am I missing?

[l2999019]

I think I found the reason.
My Oracle data has two different accounts, but in the same space it looks like this。

So when one of the libraries has a table named “_EFMigrationsHistory”, Codefirst will not create a new “_EFMigrationsHistory“, causing this error. Do you know any solution?

[alexkeh]

These are two different issues. In your first post, you are executing a SELECT against a table that does not yet exist. The solution is to scaffold the migration, then apply the model to the DB, which will then create __EFMigrationsHistory table. You can do this by following the steps in this README.

https://github.com/oracle/dotnet-db-samples/tree/master/samples/dotnet-core/ef-core

I need more information to understand what produces your second error. What is the relationship between ORACLETESTDB and MYTEST? If they are two distinct schemas, what common access does the user have in common for these schemas?

[l2999019]

These two users are in the same database instance, but they are different users.
I execute the following SQL statement in Mytest, and I can find "_EFMigration History" in ORACLETESTDB.
Is that the reason?

Because I deleted the “_EFMigrationsHistory“ table of ORACLETESTDB, Codefirst on MYTEST side can be successfully executed.
The relationship between ORACLETESTDB and MYTEST is shown below, in the same database instance.

[alexkeh]

In most situations, each Oracle user has its own separate schema.

I suspect what has happened is that you had created an EF Core schema already created for ORACLETESTDB. Then, you tried to create a new EF Core schema again before deleting the previously created tables, such as _EFMigration History.

Of course, the solution is what you found, which is deleting the previously created schema objects if you plan to start a new EF Core schema.

[l2999019]

Thank you very much for your answer