Re: ORA-03121
Date: 1996/01/29
Message-ID: <4eip7f$dc4_at_news.internetmci.com>
rick_at_novia.net (Rick Badillo) wrote:
>I just installed Oracle Workgroup Server on a Windows NT box. I am a
>first time Oracle user. The install went fine, however, I am getting
>this pesky error ( ORA-03121 : NO INTERFACE DRIVER CONNECTED)
>What does this mean? Thanks in advance.
Check the following two documents for your answer.
Document ID: 104617.217 Title: WIN: ORA-3121 and SQL*Net TCP/IP Creation Date: 17 January 1994 Last Revision Date: 20 January 1994 Revision Number: 1 Category: Desktop: RDBMS, Utilities, Networking Product: SQL*Net TCP/IP Product Version: V1.1 Platform: WINDOWS Information Type: ADVISORY Impact: HIGH Abstract: This bulletin describes a step-by-step approach toresolving ORA-3121 with SQL*Net
TCP/IP for Windows.
Keywords: SQL*NET;TCPIP;WINDOWS;3121
WIN: ORA-3121 and SQL*Net TCP/IP
This bulletin first gives an overview of SQL*Net TCP/IP for Windows and an ORA-3121 and then outlines the steps to diagnose an ORA-3121 at the end of the bulletin.
SQL*Net TCP/IP for WINDOWS overview :
SQL*Net TCP/IP for WIN V1.x as it stands today is a set of two DLLs - SQLTCP.DLL and SQLTCP1.DLL. These DLLs are loaded on the fly by the OCI DLLs when a connect string for ORACLE is identified as a TCP/IP protocol string. The ORACLE Interface DLLs will attempt to load SQLTCP. DLL first. If this fails, an attempt is made locate the DOS TSR version of the driver. If both these fail of course you get an ORA-3121.
|----------------|
| Oracle Win app |
|----------------|
| (linked with)
|-----------------|
| OCI layer : can |
| be ORA6WIN.DLL |
| or |
| ORA7WIN.DLL |
|-----------------|
| (loads on the fly)
| (and gets entry points)
| (to OSNTDS and OSNTCP - ORA-3121 may occur here !)
|-----------------|
| SQLTCP.DLL | (Initialization of DLL --fails if WINDOWS
|-----------------| (is not in ENHANCED mode--ORA-3121)
|
| (linked with)
|-----------------| (entry points OSNTRA, OSNTDS,....)
| SQLTCP1.DLL |
|-----------------|
| |
| |----------->|
| (linked with) | (linked with)
| |
|------------------| |----------------|
| ORA7WIN.DLL -- | | MSOCKLIB.DLL - |
| used by SQL*Net | | entry points to|
| for some lookup | | all TCP/IP APIs|
| routines .... | |----------------|
|------------------| | |
| (linked with) | |
| v v
|----------------| . .
| COREWIN.DLL | (Uses VSL.INI and TCP_VENDOR from ORACLE.INI
|----------------| to load a vendor specific interface DLL like
MNOVLWP.DLL or to contact the vendor specific
interface TSR like MFTP.EXE)
(1) As mentioned above, SQL*Net DLLs are loaded on the fly the OCI DLLs
in Windows. Windows when attempting to load a DLL will look in the
current working directory for the DLL, and then the WINDOWS directory
(where the WIN.COM file is located), and then the WINDOWS/SYSTEM
directory, and then each directory on the PATH. If the load failed due
to the inability to loacate the SQLTCP.DLL and SQLTCP1.DLL and no DOS
SQL*Net TSR was loaded prior to getting into WINDOWS, an ORA-3121
results.
(2) Even if the SQL*Net DLLs are locatable and get loaded by WINDOWS, they
will refuse to initialize if they detect that WINDOWS is not in 386-
ENHANCED mode.
(3) Last but not the least, ORACLE6 Windows applications (those that are
built using ORA6WIN.LIB + ORA6WIN.DLL) often turn up
with ORA-3121, even though ORACLE7 Windows applications connect
succesfully using the SQL*Net DLLs. The cause of this is that
versions of ORA6WIN.DLL earlier than 6.0.34.1.0 are not designed to
use SQL*Net DLLs. So, if there are multiple copies of ORA6WIN.DLL
on your machine rename all but the latest dated (04/13/92 or later)
DLL, and make sure it is on the PATH. Often the date on a DLL
will be misleading. So, instead one must load the DLL into a text
editor and do a text search for the string "6.0.". This will give
you the version of the DLL!! Also to verify if a particular
copy of any DLL is being loaded by WINDOWS, rename the DLL in
question to something else. Restart WINDOWS and also the application.
IF the application comes up without any errors from Windows regarding
missing DLLs, this particular copy of the DLL wasn't being used at all.
Steps to diagnose an ORA-3121:
(1) Check the connect string. Do not specify the "_at_" sign in front of the
connect string if you are explicitly providing the connect string in
the login screen. Just type in the connect string.
For example:
t:orasrv:orasid
You can also omit specifying the connect string in the login screen
and leave the field for the connect string blank if you set the LOCAL
parameter in the appropriate configuration file:
LOCAL=t:orasrv:orasid
Finding the configuration files:
********************************
Applications linked with the ORACLE7 WINDOWS DLL's (ORA7WIN.DLL) will
look at the ORA_CONFIG parameter in the WIN.INI to find the
configuration file. You should have a section in your WIN.INI that
looks like:
[Oracle]
ORA_CONFIG=C:\WINDOWS\ORACLE.INI
Applications linked with ORACLE6 WINDOWS DLLs (ORA6WIN.DLL) will use
the CONFIG variable in the DOS environment to find the configuration
file (usually CONFIG=C:\ORACLE6\CONFIG.ORA). Type SET at the DOS
prompt to see what CONFIG is set to in the DOS environment.
If you do not have CONFIG set in the environment, add a line to your
autoexec.bat to set it equal to the ORACLE.INI:
SET CONFIG=C:\WINDOWS\ORACLE.INI
Reboot after adding this line. You can also manually execute this
command from the DOS prompt, but you MUST completely EXIT Windows
before setting CONFIG and then go back into Windows.
Any parameters like LOCAL, REMOTE, SQLNET DBNAME <alias>, must be in
the appropriate configuration file. For example, to connect from
Data Browser you would place the LOCAL parameter in the ORACLE.INI
(or whatever ORA_CONFIG in the WIN.INI points to) because Data Browser
is built using ORA7WIN.DLL. To connect from Oracle Card, which is
linked with ORA6WIN.DLL, you would place the LOCAL parameter in the
CONFIG.ORA (or whatever the DOS environment variable CONFIG points to).
Please see the note at the end of this document for a list of some of
the Windows V6 products and V7 products. Please refer to the Appendix
B in your Setting Up SQL*Net TCP/IP for Windows manual for further
documentation of othe CONFIG parameters like REMOTE and SQLNET DBNAME.
(2) Windows must be in 386-Enhanced mode. Start windows with WIN /3.
(3) The SQLTCP.DLL and SQLTCP1.DLL must be on the DOS PATH. Alter the
PATH statement in the AUTOEXEC.BAT to include the ORAWIN\BIN directory.
(4) If any application is relying on ORA6WIN.DLL to connect, then the
version of the DLL must be at least 6.0.34.2.0 -- a simple string
search with a text editor on the DLL for "6.0." or "7.0" will reveal
the version number.
(5) In case of multiple copies of any DLL leave only the one with the
highest version around or simply copy the one with the latest version
onto all existing copies of the DLL. To locate multiple copies of the
ORA6WIN.DLL, follow these steps:
a) Type PATH at the DOS prompt and <RETURN>. Make a note of all DRIVES
currently in your path (C:, D:, etc..).
b) Do a search on all the above DRIVES in the DOS path on a file called
ORA6WIN.DLL (recommended ways are using the FILEFIND utility from
Norton or by simply doing a DIR ORA6WIN.DLL /S in DOS 5.0 or
later, from the root directory. You may also use the File Search
utility in Windows File Manager).
If you have multiple copies of the ORA6WIN.DLL, rename all the copies
of the file (to something such as ORA6WINX.DLL), EXCEPT ONE. Ensure
that this copy of the ORA6WIN.DLL is either dated 4/13/92 (285573 bytes)
or 10/15/92 (380639 bytes). These two versions of the ORA6WIN.DLL were
distributed directly by Oracle Corporation. If you have a file that is
dated later than 10/15/92 and is of a size larger than 380639 bytes,that
may work too. As mentioned above, the date of the ORA6WIN.DLL must be
v6.0.34.2.0 or later.
(If you do not have a copy of the ORA6WIN.DLL with one of the above
dates then contact the vendor of your third party application for a copy
of this file. If you have any other Oracle product with a disk labeled
"Windows Required Support Files Version 6.0.xx.x.x" then this should
also have a current copy of the ORA6WIN.DLL).
c) Make a note of the directory that the ORA6WIN.DLL resides in.
d) Ensure that the above directory is in the current PATH. Verify by
typing PATH and <RETURN> at the DOS prompt.
Document ID: 103883.585
Title: ORA-03121 and SQL*Net for Windows
Creation Date: 08 September 1993
Last Revision Date: 17 October 1994
Revision Number: 3
Product: SQL*Net
Product Version: V1 and V2
Platform: WINDOWS
Information Type: ADVISORY
Impact: HIGH
Abstract: This bulletin describes a step-by-step approach to
resolving ORA-03121 ("no interface driver connected -
function not performed") errors when attempting to
connect to a remote Oracle RDBMS using SQL*NET for
Windows.
Keywords: SQLNET;WINDOWS;3121
------------------------------------------------------------------------------
ORA-03121 and SQL*Net for Windows
This bulletin describes a step-by-step approach to resolving ORA-03121 ("no interface driver connected - function not performed") errors when attempting to connect to a remote Oracle RDBMS using SQL*NET for Windows with Oracle Version 6 products (see the end of bulletin for a description of these products).
ORA-03121 with SQL*Net V2
You will get an ORA-03121 when trying to connect via SQL*Net V2 if you do not use the "tns:" net prefix in the connect string if you're using an Oracle V6 based application. An Oracle V6 based application means that the application is linked to use ORA6WIN.DLL. If the application is linked to use ORA7WIN.DLL, the "tns:" prefix is not needed.
Be careful not to use the old V1 net prefixes. A V2 connect string consists of the tnsnames.ora alias. This is the first line in your tnsnames.ora file, which is located in either c:\orawin\network\admin directory or in the directory set by TNS_ADMIN in the oracle.ini file.
Here's an example of a tnsnames.ora file:
test1 = (DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = prodserv)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SID = db1)
)
)
In this example, the alias is test1 so you would connect as follows: connect scott/tiger_at_test1 (if using an application linked with ORA7WIN.DLL) connect scott/tiger_at_tns:test1 (if using an application linked with ORA6WIN.DLL)
ORA-03121 with SQL*Net V1
- EXIT from Windows to the DOS prompt.
- Type PATH at the DOS prompt and <RETURN>. Make a note of all DRIVES currently in your path (C:, D:, etc..).
- Do a search on all the above DRIVES in the DOS path on a file called ORA6WIN.DLL (recommended ways are using the FILEFIND utility from Norton or by simply doing a DIR ORA6WIN.DLL /S in DOS 5.0 or later, from the root directory. You may also use the File Search utility in Windows File Manager).
If you have multiple copies of the ORA6WIN.DLL, rename all the copies of the file (to something such as ORA6WINX.DLL), EXCEPT ONE. Ensure that this copy of the ORA6WIN.DLL is either dated 4/13/92 (285573 bytes) or 10/15/92 (380639 bytes). These two versions of the ORA6WIN.DLL were distributed directly by Oracle Corporation. If you have a file that is dated later than 10/15/92 and is of a size larger than 380639 bytes, that may work too.
(If you do not have a copy of the ORA6WIN.DLL with one of the above dates then contact the vendor of your third party application for a copy of this file. If you have any other Oracle product with a disk labeled "Windows Required Support Files Version 6.0.xx.x.x" then this should have a current copy of the ORA6WIN.DLL)
4. Make a note of the directory that the ORA6WIN.DLL resides in.
5. Ensure that the above directory is in the current PATH. Verify by typing
PATH and <RETURN> at the DOS prompt.
6. Verify that the ORAWIN\BIN directory is also in your current path
(or wherever your SQL*Net for Windows is installed. If you are not sure, then it should be the ORACLE_HOME\BIN directory, where ORACLE_HOME is defined in the ORACLE.INI file. See Step 7 below). Also check to make sure that the SQL*Net DLL's exists in the ORACLE_HOME\BIN directory (for example, SQLSPX.DLL and SQLSPX1.DLL for SQL*Net SPX for Windows, and SQLTCP.DLL and SQLTCP1.DLL for SQL*Net TCP/IP for Windows). You should also have ORA7WIN.DLL in the ORACLE_HOME\BIN subdirectory.
7. Edit the WIN.INI file in the WINDOWS directory. Ensure that you have a
group called Oracle which looks something like:
[Oracle]
ORA_CONFIG=C:\WINDOWS\ORACLE.INI
7a) Type SET at the DOS prompt again and <RETURN>. Check to see if a DOS
environment variable called CONFIG is set to point to a file called CONFIG.ORA. You will see something like:
CONFIG=C:\ORACLE6\CONFIG.ORA b) If you do not have the CONFIG variable set in the environment, add the
following statement to your autoexec.bat file and re-boot:
SET CONFIG=C:\WINDOWS\ORACLE.INI
(Put the appropriate path to your Windows directory).
If CONFIG was not set and you had to do step 7b, then skip step 8.
8. Ensure that the RDBMS70 in ORACLE.INI is pointing to the correct location
((f:oranw\rdbms70 for the server instead of g:\orainst\rdbms for the client)
9. Match the following parameters in the CONFIG.ORA and the ORACLE.INI
EXACTLY (see above steps for the locations of these files). Some of these parameters may not exist in both the files! We want to ensure that these parameters match exactly if they are present in either the CONFIG.ORA or the ORACLE.INI. If some of these parameters do not exist in both the files, don't add them. Also, some of these parameters may be unnecessary, but adding them in both the CONFIG.ORA and the ORACLE.INI will not hurt.
List of Parameters:
WIN_LOCAL_SESSIONS
WIN_REMOTE_SESSIONS
LOCAL
REMOTE
INTERRUPT
XMMITR
TCP_HOSTS_FILE
TCP_SERVICES_FILE
SQLNET DBNAME
- Launch Windows now and ensure that Windows is coming up in ENHANCED mode by clicking on HELP in Program Manager and clicking on ABOUT PROGRAM MANAGER here. SQL*NET for Windows WILL NOT WORK in Standard mode.
- Do not specify the '_at_' sign in front of the connect string if you are explicitly providing the connect string in the login screen. Just type in the connect string, for example:
t:orasrv:orasid or x:orasrv
- You can also omit specifying the connect string in the login screen and leave the field for the connect string blank if you set the LOCAL parameter in the ORACLE.INI and CONFIG.ORA: LOCAL=t:orasrv:orasid
- Call Oracle Worldwide Support if the problem is still not resolved and if you have a valid CSI or PC-Registration number.