Search code examples
oracle-databasebiztalktnsnames

BizTalk WCF ORA-12154: TNS:could not resolve the connect identifier specified

I have a BizTalk 2013r2 app with a WCF-Oracle send port running under a 32bit host.

When run in my test environment it works fine. However, on my dev box I get the following error:

"ORA-12154: TNS:could not resolve the connect identifier specified"

The address set on the send port is "oracledb://test_godw_lincoln/" . My understanding is that the ip address and port should be resolved from the local tnsnames.ora file. I have a system environment variable for TNS_ADMIN set correctly:

enter image description here

From a command prompt, if I enter "set tns_admin" then the following is displayed:

TNS_ADMIN=C:\app\biztalk.admin\product\12.1.0\client_1\Network\Admin

If I open the file "C:\app\biztalk.admin\product\12.1.0\client_1\Network\Admin\tnsnames.ora" then I see the following entry:

test_godw_lincoln =
   (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = xx.xxx.xx.xx)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = gotest) 
    )
  )

(I've substituted the real IP address)

If I open Sql Developer on the same dev vm then I am able to open a connection to the required database using the tnsname entry "test_godw_lincoln":

enter image description here

I realise that Oracle can be addressed from the adaptor without using tnsnames.ora but I understand that if ambient transactions are to be used (the app does make use of them) then the address must be via tnsnames.ora

Any suggestions as to how I can track down the cause of the problem with this particular VM?

Re question from Dmitir - the registry is empty:

registry

Re suggestion from Felix - I am able to create the connection on the same dev server from Visual Studio server explorer:

enter image description here

However, if I try to connect from the "Consume Adapter Service" wizard (add generated items) then I get the ORA-12154 error:

enter image description here

Solution

  • This came down to a mysterious problem with the tnsnames.ora file. The suggestion from @Hichamveo helped but rather that try my bad tnsnames.ora file on a working environment, I copied the tnsnames file from an environment that worked. I found that the dev VM then started working - so I knew the problem was with the tnsnames.ora file rather than ODAC / ODP.Net assemblies.

    I then spent quite some time trying to figure out exactly what was broken with the bad tnsnames file. I used file compare tools and tried a linter at: http://brantwills.github.io/tns-check/ but these showed no problems.