Re: Error:ORA-12203:TNS:unable to connect...
From: Reza Abouk <rabouk_at_mcimail.com>
Date: 1996/02/21
Message-ID: <4gfcpp$qhs_at_news.internetmci.com>
Date: 1996/02/21
Message-ID: <4gfcpp$qhs_at_news.internetmci.com>
soonam_at_list.gmu.edu (Soonam Kahng) wrote:
>Wile I installing and testing..
>I got the following messages "ORA-12203:TNS:unable to connect to
>destination". I don;t have any idea for this error message.
>Would you give me some clue ?
>thank you.
><Soonam>
Document ID: 104800.493 Title: WIN: TNS-12203 and V2 TCP/IP Adapter Creation Date: 31 January 1994 Last Revision Date: 15 March 1995 Revision Number: 1 Product: SQL*Net TCP/IP Product Version: V2 Platform: WINDOWS Information Type: ADVISORY Impact: HIGH Abstract: This bulletin explains the possible causes for getting a TNS-12203 with the V2 TCP/IP Adapter for Windows. Keywords: SQL*NET;WINDOWS;TCPIP;12203;ADAPTER ----------------------------------------------------------------------------- WIN: TNS-12203 and V2 TCP/IP Adapter The error TNS-12203 "TNS: unable to connect to destination" can be caused for several different reasons. This bulletin lists the most common ones. 1) You can get a TNS-12203 when trying to connect if you do not have the
TCP/IP Adapter for Windows installed. SQL*Net TCP/IP V2 really consists of two separate products: SQL*Net V2 and the V2 TCP/IP Adapter. These
are two separate kits. Be sure that you have both of them installed.
2) As mentioned in the Release Notes, TNS-12203 error could indicate that
the ORACLE SQL*Net for Windows software cannot find the ORACLE home
directory. To correct the problem, first verify that your WIN.INI file
contains the following entry in the ORACLE section:
[ORACLE]
ORA_CONFIG=C:\WINDOWS\ORACLE.INI
If your Windows directory is not C:\WINDOWS, substitute its name for the
C:\WINDOWS part of the above line. Then verify that your Windows
directory has an ORACLE.INI file. If not, use the ORAINST program to
install your ORACLE software again. If it does contain an ORACLE.INI,
verify that the ORACLE.INI file contains the following line:
ORACLE_HOME=C:\ORAWIN
If your Oracle home directory is not C:\ORAWIN, substitute its name for
the C:\ORAWIN part of the above line.
3) If you are going through a Windows application and get TNS-12203, Verify
that the TNSNAMES.ORA resides in the $ORACLE_HOME\NETWORK\ADMIN directory. The Oracle home directory is defined by the ORACLE_HOME parameter in the ORACLE.INI file (or whatever file is pointed to by the ORA_CONFIG parameter in the WIN.INI). The variable TNS_ADMIN is not defined in the ORACLE.INI file. Hence, file the location of TNSNAMES.ORA in the default
location:
$ORACLE_HOME/network/admin
4) You can also get a TNS-12203 if there is not a SQL*Net V2 TCP/IP
listener running on the server side. Confirm that you have SQL*Net V2
running on the server side. You can use the Listener Control
Utility (LSNRCTL) on the server side to verify that the V2 listener
on the server is up and running. On the server, execute the command
"LSNRCTL STATUS". Please refer to chapter 7 in the SQL*Net
Administrator's Guide for more information about the Listener Control
Utility.
5) Verify that you have specified the correct ADDRESS parameters in the
connect descriptor for the service_name you are trying to connect to.
A good way to confirm that you are using the correct ADDRESS parameters
is to attempt a loopback on the server using a TNSNAMES.ORA with the
same ADDRESS parameters you are trying to use from the Windows client.
Performing a loopback means invoking a front end tool (like SQL*DBA)
on the same machine as the database and specifying a connect string
to make the connection via SQL*Net V2.
6) You can get a TNS-12203 if the JSB VSL socket is not initialized.
To correct the problem, verify that the JSB VSL layer is correctly
initialized by checking the following (as mentioned in the Release
Notes):
a) make sure the vendor key parameter, TCP_VENDOR, is correctly
set in the ORACLE.INI file (or whatever file is pointed to by
the ORA_CONFIG parameter in the WIN.INI).
b) make sure the MSOCKLIB.DLL is present in the ORACLE_HOME\BIN
directory.
c) make sure the JSB vendor-specific DLL for the selected vendor
is present in your ORACLE_HOME\BIN directory, or that that
JSB vendor-specific TSR file is executed.
d) make sure the VSL.INI file is present in the WINDOWS home
directory.
7) The TNS-12203 might be followed by another error which might give
more of an indication of what the actual problem is. If you did not
receive any other errors on the screen, check the SQLNET.LOG file
in the ORACLE_HOME\NETWORK\LOG directory.
8) When using the V2 APPC Adapter for Windows: the alias descriptor in the
tnsnames.ora file should have the value for PLU_LA always in upper case or
a TNS-12203 will result. This is irrespective of the case used in the
SIDEINFO.NSD file for the symbolic destination name.
e.g
os2=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=LU62)
(PLU_LA=os2))) will result in TNS-12203
but
os2=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=LU62)
(PLU_LA=OS2)))
will connect fine; where os2 or OS2 is defined as the SYMBOLIC DESTINATION
NAME in the SIDEINFO.NSD file.
9) If your system was working, but now all of a sudden you're getting a
TNS-12203 error, you might try reinstalling SQL*Net and the TCP/IP
adapter as a last resort.
10) You can get a 12203 error if VSL.INI is not located in the Windows main
directory. Simply reinstall SQL*Net (or copy the file off the SQL*Net
TCP/IP adapter diskette).
11) Ensure the TNSNAMES.ORA file is in the $ORACLE_HOME\NETWORK\ADMIN
directory. The variable TNS_ADMIN is also not defined in the oracle.ini
file. Hence, the location of TNSNAMES.ORA should be in the default
location:
$ORACLE_HOME/network/admin
12) If you are trying to connect through nettest using FTP PCTCP v2.3 Winsock
and getting ORA-12203 (TNS-12203), you may have multiple copies of
winsock.dll in the C:\PCTCP directory.
13) If you get a 12203 error after opening several sessions, and after
disconnecting can open fewer and fewer sessions before getting a 12203
error, then ensure himem.sys is in the CONFIG.SYS file.
---------------------------------------------------------------------------
Oracle WorldWide Customer Support
Received on Wed Feb 21 1996 - 00:00:00 CET