I'm using Visual Studio 2013 and Entity Framework 6.1.3 against a legacy Oracle 12c database to generate a database first EDMX model. The problem I'm encountering is that for some tables, only a Storage Model definition of the table is generated, but it should be generating both a Storage Model definition and a Conceptual Model definition. Without the conceptual model definition, C# classes are not getting generated, so I can't use the tables.
Info about the tools that I'm using:
I've been trying to figure out how to fix this for a couple days now. I've only found one reported instance on the web that even comes close to what's happening to me (https://www.codeproject.com/Questions/1102413/EF-doesnt-add-all-tables-in-conceptual-model), but there is no reported solution to that problem.
The EDMX that I'm trying to add the tables to currently holds about forty table definitions. The interesting thing is that I can create a separate, empty EDMX file and successfully add my problem tables sometime, but not all the time. I was thinking about generating the definitions for my tables in the separate EDMX and then copying them to the original EDMX, but I'm not confident that I would successfully include all of the necessary markup, especially when trying to include navigation links between other tables. Also, this would be horrible to have to do every time I encounter a table that has this problem.
Various solutions to EF problems say to "Run the Custom Tool", but that won't work in this case because of the missing conceptual model information.
Thanks for any help.
I finally figured out what was happening. One of the "problem" tables was not actually a problem, just my misunderstanding of how Entity Framework works. This table was a pure join table having only two columns: one column pointing to table A and the other to table B. Entity Framework does not generate a class for a pure join table. Instead, it just converts it to navigation links on the classes of the two joined tables (class A and class B).
The problem with the second table was real, and was caused by mismatched column definitions in the database. A foreign key definition had a column of type NUMBER(18) on one side and a column of type NUMBER(22) on the other. EF was converting the NUMBER(18) to long, and the NUMBER(22) to decimal. EF apparently does NOT like having differing C# types on the ends of its navigation links.
To resolve the problem, I modified my EDM number mapping (see https://docs.oracle.com/cd/E56485_01/win.121/e55744/entityDataTypeMapping.htm#BABGBJCI) so that NUMBER(18) and NUMBER(22) both resolved to long. I then removed all of my table definitions from the EF Designer and re-added them so that all of my field types would regenerate. I assume I could have also resolved the problem by fixing the mismatched types in the database, but I found the same problem in a couple dozen more places, so I went with the code solution.