Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Oracle ODP.NET Fallback to the unmanaged provider
 

Pages: 1
LLBLGen Pro Runtime Framework
Oracle ODP.NET Fallback to the unmanaged provider
Page:1/1 

  Print all messages in this thread  
Poster Message
greenstone
User



Location:
Alexandria, VA, USA
Joined on:
20-Jun-2007 03:39:56
Posted:
126 posts
# Posted on: 04-Oct-2019 17:12:59.  
Hi,

I'm using llblgen version 5.5.4.0 (runtime library version) using "adapter" and using Oracle as my database. I'm also running under .NET Framework 4.7.

We seem to be seeing a behavior (on a customer's server...to which I don't have access) where Oracle.ManagedDataAccess.Client is specified in the connection string in web.config of my asp.net application appears like it might be falling back to using the unmanaged Oracle client.

We have: <add key="ODPNETAlwaysChooseUnmanagedProvider" value="false" /> set in the web.config.

The connection string is:
<add name="MyConnection" connectionString="Data Source=MYSID;User Id=MyUser;Password=temp;" providerName="Oracle.ManagedDataAccess.Client" />

Is there some fallback "magic" that will use the unmanaged oracle dataaccess, if the managed dataaccess is not installed or otherwise not available on the server?

(I'm trying to diagnose why the managed driver does not seem to be being used. I suspect it might not be installed on his server)

Thanks!
Andy  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37638 posts
# Posted on: 04-Oct-2019 20:24:31.  
It's using a simple algorithm: it first tries to obtain the factory for the managed provider (see the machine.config file for the 64 bit .net installation on the machine (I assume you're not running a 32bit app Wink) which is located in \windows\microsoft.net\framework64\config

This uses the invariant name "Oracle.ManagedDataAccess.Client"
If it's not found, it assumes the unmanaged client is to be used, and it'll try to obtain the factory for that, using "Oracle.DataAccess.Client"

If that's also not present, it will stop (as it can't produce commands/connections etc.) and will report an error that it can't load the factory.

It might be you have an old ODP.NET installed, as recent ODP.NET installations install the managed client as well. It might also be (but I haven't checked) they don't ship the managed client anymore with odp.net but instead solely through nuget.

If that's the case, you can use it through the Runtime Configuration system in the runtime and register the factory that way (reference the managed odp.net package in your project which calls the Runtime configuration , see: https://www.llblgen.com/Documentation/5.6/LLBLGen%20Pro%20RTF/Using%20the%20generated%20code/gencode_runtimeconfiguration.htm )


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
greenstone
User



Location:
Alexandria, VA, USA
Joined on:
20-Jun-2007 03:39:56
Posted:
126 posts
# Posted on: 04-Oct-2019 21:24:33.  
Hi Otis,

Thanks for the reply and info.

Actually, I believe they are running the 32bit application (they have the 32-bit ODP.NET installed).

Is the algorithm any different for 32bit? (other than located in: Windows\Microsoft.NET\Framework\v4.0.30319\Config)

Andy  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37638 posts
# Posted on: 05-Oct-2019 08:49:52.  
Indeed, same thing, but now you have to check the 32bit config file in that folder indeed. Our code uses DbProviderFactories.GetFactory() so we're not directly checking these files, that .NET class does. It depends on whether your app is 32 or 64 bit which config file DbProviderFactories is checking.



Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.