0
votes

We have a web site, .Net framework 4.0, 64-bit, hosted in IIS 7.5, running on Windows Server 2012. It is using Windows Authentication. It is using 64-bit 12c ODP.NET client, version 4.121.2.0. The web site has its own application pool. When the application pool is configured to use a Domain account as the identity, it works. When we change the application pool to run under the ApplicationPoolIdentity as is recommended practice, we get "Failed to establish database connection: The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception."

Based on some threads, I have given the IIS AppPool\AppPoolName access to the ODP.NET and the bin folders under the Oracle 12g client install path, but still get the same error.

Note that I have seen the thread relating to an SQL Server authentication problem to which there is a Microsoft KB saying reboot the server after a password change, but that only applies to Windows 7 and Windows 2008.

Code. N/A

1

1 Answers

0
votes

This turned out to be a permissions issue. The original error I posted only included the exp.Message. I then added the exp.InnerException to the message and got this:

Error: Failed to establish database connection: The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception., Inner Exception: System.TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'OraOps12.dll': Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at Oracle.DataAccess.Client.OpsInit.CheckVersionCompatibility(String version) at Oracle.DataAccess.Client.OracleInit.Initialize() at Oracle.DataAccess.Client.OracleConnection..cctor() --- End of inner exception stack trace --- at Oracle.DataAccess.Client.OracleConnection..ctor(String connectionString) at CLASS.Common.Database.ClassDbConnection.Open(String connectionStr)

We got around this by adding read and execute permission for the IIS AppPool/AppPoolName to the folder structure where the Oracle 12 client was installed. It turns out that ODP.Net install involves more folders under the client root than just the odp.net folder.

All this should not be necessary but we operate within an environment where we do not always set the security policies.