Normally this is an easy error to correct. First thing, check the TNSNAMES.ORA entry for the service name in question.
An example looks like this:
ORA11 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = zedatabaseserver)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ORA11)
)
)
First thing: Check to make sure the host name is correct. If it is, try resolving it on the client; use either nslookup or ping.
If that resolution is correct, the next thing to try is to change the host name to the IP address. So, in the above entry changing the host name would look something like this:
ORA11 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ORA11)
)
)
That usually does it. Further problems are usually easy to diagnose; a complete lack of all network connectivity indicates the NIC has a problem, or someone's tripped over the cable again.
This time, none of the usual fixes worked. Even stranger, the problems only showed up in part of the application. Anything that used Crystal Reports, which itself used an ADO connection object, was refusing to connect.
The main application, and tools like SQL*Plus, worked fine. Eventually, multiple edits to the TNSNAMES.ORA file seemed to fix the problem, but I don't see how. We rather suspect someone from the server group was fiddling and "unbroke" whatever it was after they applied patches.
Very strange. If anyone else out there has seen something like this, feel free to leave a comment here.
UPDATE: Think I figured it out.
No comments:
Post a Comment