We Keep Coding

EF6 database first for Oracle sometimes not generating a class for a table

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:
Visual Studio 2013 v. 12.0
.NET 4.5.2
Entity Framework 6.1.3
Oracle 12c
Offical Oracle ODP.NET, Managed Driver 12.1.2400
Official Oracle ODP.NET, Managed Entity Framework Driver v.12.1.2400
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.

ASP.net MVC : Create MVC 5 Application using EF6 with Code First and Existing Database

I have to create an application in MVC 5 using EF6. I have already created the schema for the database in SQL Server 2012 and now I want to query this in my app.
The workflow that seems fit is Code First with Existing Database and I have tried to follow below resources but they are a little confusing to me as I am a beginner.
Is there a way I can still use my DB schema in SQL server and go ahead with Code First approach using generated data models from DB.
http://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
http://www.asp.net/mvc/overview/getting-started/introduction/getting-started

Yes you can reverse engineer code first from existing DB schema. Here you can find instructions how do do it. Since you already created your DB schema you can start from point 3. Reverse Engineer Model.
This process will create for you a DbContext, POCO classes for the tables you selected in the wizard and the mappings. You can use it to query your DB.
When your DB schema changes in the future you can either regenerate POCO classes again or simply edit them by hand (if column type changed simply change the property type, if new column was added add new property to your class). Most devs use reverse engineer code first from existing DB only as a starting point when they need to target existing legacy database. After initial creation all future changes in schema are reflected by manually editing the classes that were originally generated by the tool.

Entity Framework 6- Dynamic entities

My company has 100’s of databases with few thousands of entities including Tables, SP and Views.
I am creating a generic Data layer using Entity Framework 6 for my company’s ad hoc projects such that developers don’t have to bother about the underlying database.
My project contains Empty Data Model (.edmx).
Now based on the user selection I need to set the connection and get the entities at run time. Once these entities are registered, I need to provide a collection of data to the caller.
For example: A developer invokes the method from my class and pass entity name as enum string .say … “Entity.Orders”
Here.. my code knows that “Orders” belong to Database named “Sales” which is on “SalesBox” server.
My code now sets up the connection to “Sales” database, get the rows from “Order” table, create a List collection (or any appropriate) and return the collection to caller.
Is this all possible using EF 6? If yes How?

EF Initializer with multiple contexts for one database

I have an existing application with a SQL database that has been coded using a database first model (I create an EDMX file every time I have schema changes).
Some additional development (windows services which support the original application) has been done which uses EF POCO/DbContext as the data layer instead of an EF EDMX file. No initializer settings were ever configured in the DbContexts, but they never modified the database as the DbSet objects always matched the tables.
Now, I've written a seperate application that uses the existing database but only its own, new tables, which it creates itself using EFs initializer. I had thought this would be a great time to use EF Code First to handle managing these new tables. Everything worked fine the first time I ran the application, but now I am getting this error from some of my original EF POCO DbContexts (which never used an initializer).
The model backing the 'ServerContext' context has changed since the
database was created. Consider using Code First Migrations to update
the database
After some investigation, I've discovered that EF compares a hash of its schema with some stored hash in the sql server somewhere. This value doesn't exist until a context has actually used an initializer on the database (in my case, not until the most recent application added its tables).
Now, my other DbContexts throw an error as they read the now existing hash value and it doesn't match its own. The EF connection using the EDMX doesn't have any errors.
It seems that the solution would be to put this line in protected override void OnModelCreating(DbModelBuilder modelBuilder) in all the DbContexts experiencing the issue
Database.SetInitializer<NameOfThisContext>(null);
But what if later on I wanted to write another application and have it create its own tables again using EF Code first, now I will never be able to reconcile the hash between this theoretical even newer context and the one that is causing the issue right now.
Is there a way to clear the hash that EF stores in the database? Is EF smart enough to only alter tables that exist as a DbSet in the current context? Any insights appreciated.

Yes, Bounded DB contexts is actually good practice.
eg a base context class, to use common connection to DB, each sub class, uses the
Database.SetInitializer(null); as you suggest.
Then go ahead and have 1 large context that has the "view of the DB" and this context is responsible for all migrations and ONLY that context shoudl do that. A single source of truth.
Having multiple contexts responsible for the DB migration is a nightmare I dont think you will solve.
Messing with the system entries created by code first migrations can only end in tears.
Exactly the topic you describe I saw in A julie Lerman video.
Her suggested solution was a single "Migration" context and then use many Bounded DB contexts.
In case you have a pluralsight account:
http://pluralsight.com/training/players/PsodPlayer?author=julie-lerman&name=efarchitecture-m2-boundedcontext&mode=live&clip=11&course=efarchitecture

What EF version are you using? EF Code First used to store hash of the SSDL in the EdmMetadata table. Then in .NET Framework 4.3 thingh changed a little bit and the EdmMetadata table was replaced by __MigrationsHistory table (see this blog post for more details). But it appears to me that what you are really looking after is multi-tenant migrations where you can have multiple context using the same database. This feature has been introduced in EF6 - (currently Aplpha2 version is publicly available) Also, note that EdmMetadata/__MigrationHistory tables are specific to CodeFirst. If you are using the designer (Model First/Database First) no additional information is stored in the database and the EF model is not checked whether it matches the database. This can lead to hard to debug bugs and/or data corruption.

How to get entity framework to realize the model and the DB are in sync

I am using Entity Framework code first for the first time in a production environment. Everything went fine until we got the DB up and had put some of the data in it and then to get some of the data we were importing from another location we had to change field lengths. So we made some of the fields nvarchar(99) instead of nvarchar(50).
That went fine and the application still worked but I knew I needed to change the data annotation or it would blow up later when it loaded and tried to save a too long field. When I did that the app blew up even though the model and the db are now matching. So I thought that it was the hash in the metadata table so I thought I'd be clever and make a new DB and take the hash from there and copy it. That did not work and in fact now I cannot get my app to connect to the test db that we have data loaded in at all.
I do not want to drop and recreate this database. I want entity framework to realize that the model and the schema do in fact match. Is there any way for me to do this? Also why did copying the metadata from a DB that entity framework created with this model not work?

Entity Framework Code First creates a EdmMetadata table and saves a hash of your Model classes in it. When you change something in the Model, the hash of the new Model classes doesn't match what's in the EdmMetadata table anymore, and the app should "blow up" at runtime. What you need to do to keep using the same database without dropping it, is to delete the EdmMetadata table. This way EF will not do that check and will try to proceed with the access to the DB.
Check this video tutorial (skip to 8:10 of the "When Classes Change" section).

Sorry I fixed this. Removing the metadata worked. But turns out I had updated to a more recent version of EntityFramework accidentally while trying to fix my problem and this more recent version expected different naming conventions for the Database. In any case recreating the many-to-many group person table with a script from a DB created by Entity Framework and deleting the metadata fixed the problem.