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

  • Question

  • 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. 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":


    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?

    For details please see: https://stackoverflow.com/questions/48360232/biztalk-wcf-ora-12154-tnscould-not-resolve-the-connect-identifier-specified



    Sunday, January 21, 2018 6:49 AM

Answers

  • As documented on the Stack Overflow post - the problem was due to a corrupt tnsnames.ora file. Once I'd taken a copy from another server it worked ok. 
    • Marked as answer by Rob Bowman UK Tuesday, January 23, 2018 9:34 AM
    Tuesday, January 23, 2018 9:34 AM