All,
Hi. We have a .NET Framework 4.8 project that we would like to upgrade to the Oracle.ManagedDataAccess Nuget package.
The project is currently at 21.11.0 and we have tried upgrading it to the latest (as of 7.11.24) version of 23.4.0.
When we upgrade the package, the application fails with an “ORA-12154: Cannot connect to database. Cannot find alias [SERVERNAME] in DataSources, LDAP” (where, [SERVERNAME] is the alias of the DB we want to connect to). All of this code worked prior to the upgrade and works if we upgrade the Nuget package to 21.14.0 (the prior release version of the package).
After much searching, we found that the issue is being caused by our ldap.ora file (located in our Oracle network admin directory). In this file we have the following line:
DIRECTORY_SERVERS= (SERVER-OID-P1:3060:3131, SERVER-OID-P1:3060:3131)
There is a space between the two servers (after the comma separating the two server names).
If we change the line and remove the space in the ldap.ora file to:
DIRECTORY_SERVERS= (SERVER-OID-P1:3060:3131,SERVER-OID-P1:3060:3131)
then the 23.4.0 version works great.
Unfortunately, our sys admins and DBAs say that we should not remove the space and, caution that, if we do, the space might get re-added when they push updated ldap files to our servers (which they do on occasion).
They suggested that we read the ldap file ourselves, remove the space and set the Oracle.ManagedDataAccess.Client.OracleConfiguration.DirectoryServers value to the updated string (with no space) in our code
I should note that they want us to use the ldap file (instead of putting these settings in our config file or putting the ldap file in our bin) so that all applications on our servers are controlled in one place (ie, if we need a change, we change the ldap file and not each web.config (since multiple apps reside on these servers).
I know that we could read the ldap file ourselves and set the DirectoryServers property to the updated string in code but would really rather avoid that if there is an easier way to do this (or if the next Nuget package is going to fix/address this).
Any thoughts/ideas would be appreciated.
Thanks,
Jason