Entity Framework to the rescue
Oracle Entity Framework Provider Beta
I am a huge fan of Entity Framework and all of the time it saves. If you're like me, and often have to connect to Oracle for your .NET projects, I'm sure you were as happy as I was when Oracle finally released a provider that works with Entity Framework and LINQ to Entities.
I have been using the Oracle Entity Framework Provider Beta (OEFPB) for about a week and really like it. It seems to work quite well, although I have seen a few strange things happen. Here are some issues I've come across and how I solved them.
I'm not sure if all providers work the same way, but if the OEFPB can't determine a unique primary key for your table/view, you can forget about it pulling it into Entity Designer's "Choose your Database Objects" wizard. It pretends you can add it, but the wizard closes and nothing new shows up in the designer. Helpful right? Nope. You will have to add a primary key to your database object before you can import it into your model.
The download page clearly states "32-bit" right on it, but of course, I didn't read that part. I found this out the hard way after installing the provider onto a server, which kept throwing strange exceptions until it finally told me this, "Unable to find the requested .Net Framework Data Provider. It may not be installed".
But it sure was installed. I even checked the PATH in my environment variables and restarted the server. Once I realized it was a 32-bit provider running on a 64-bit machine, I quickly remembered the Application Pool Advanced Settings that looks like:
Changing the "Enable 32-bit Applications" to True fixed it!
Hopefully these tips will save you some time and effort figuring out the quirks that come with the Oracle Entity Framework Provider Beta. I will keep you posted on any other fun things I come across.
Great to finally get some feedback on the new beta provider.
FWIW, the first problem is an EDM designer problem, not specific to that provider. If you don't have a PK, EF will try to infer one by combining all available non-nullable keys. If there are none, then no entity will be created.
Thanks for the pointers.
Julie, I kind of assumed the primary key issue was more the designer than the provider. I was definitely trying to bend the rules a bit when I created the key-less materialized view and tried to wire it up to EF. The problem was just solved by adding a primary key generated by a sequence, then ignoring that field within my generated entity.
I also ran into a strange problem when I added entities from the database into my model (quite large at the time), the designer would add other entities with very long strange names like "BIN_13813581sd381s38d3sd1d1f5". They would always come in pairs and would show up every time I added a new table or view. They contained fields from another table that was in my schema, but not the one I was importing. Unfortunately, or maybe fortunately, I can't reproduce it now and provide a screenshot.