Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Help SQL Plus 3.3 will not connect from Win-95

Re: Help SQL Plus 3.3 will not connect from Win-95

From: Ian Hill <hilli_at_cea.curtin.edu.au>
Date: Wed, 12 Aug 1998 17:05:02 +0800
Message-ID: <35D15ABE.B9CB058F@cea.curtin.edu.au>


Ian Hill wrote:

> Environment
> Server runs 7.3.3, PC under Win-95 runs 3.3. IP address assigned, all
> internet browsing, telnet etc working fine.
>
> Problem:
> * Cannot find TNC, either with SQL-Plus, or with tnsping. SQL Plus
> just
> hangs until it times-out.
> * The alias is properly set up (compared this with another 'working'

One of my colleagues came up with a list of possibilities. Number 15 on the list turned out to be the answer.....setting TNS_ADMIN in the registry. The normal installation had NOT set this, and I didn't see that setting on the other PC installations, but once I added it, SQL-Plus connected immediately. Thanks to everyone, global and local who helped with this one.

Ian
---

Resolving ORA-12154 Using SQL*Net and Windows Platforms


***Note: Windows Platforms includes Windows 3.11, Windows 95, and NT.

The ORA-12154 means that SQL*Net could not find the connect descriptor specified in the TNSNAMES.ORA file.

If connecting from a Windows client, after verifying that the database is
turned on, check the following:

  1. If connecting via a login box, do not begin the field for the connect string with an @ sign. The @ sign should only be used if specifying the connect string in command line mode: sqlplus scott/tiger_at_tns:<service name >

    For SQL*Net V2, the field for the connect string should be:

         tns:db_alias   (if the application you are connecting to
                         uses ora6win.dll)
      - or -

         DB_alias       (if the application you are connecting to
                         uses ora7win.dll)

    If you are not sure whether your application uses ora6win.dll or     ora7win.dll, specify the tns: prefix. Ora7win.dll will accept the     tns:prefix as well.

2. Make sure you have a TNSNAMES.ORA on the client. Ensure that you have

    a descriptor alias in the TNSNAMES.ORA file you are specifying in the

    connect string. By default, the TNSNAMES.ORA is in the     $ORACLE_HOME\network\admin directory.

3. Make sure there are no mismatched parentheses in the TNSNAMES.ORA.

4. If the configuration files were not created with one of the configuration

    tools, many syntax errors may exist. The solution is to create the     configuration files using NET_CONF or Network Manager, depending on what

    version of SQL*Net you're using. One possible error is not having the

    correct alias name. If you have 'service_name' instead of the actual

    alias, this would be incorrect. Usually the alias is set equal to the

    SID. Make sure your TNSNAMES.ORA file is the same on both the server and

   the client.

5. If you are not using MultiProtocol Interchange (MPI), remove the

    tnsnav.ora file.

6. Turn on client tracing and re-execute the operation. The client trace

    file will show a secondary error code. To turn on client tracing, add

    (or increase) the variable 'trace_level_client=16' in the file:

         \Oracle_Home\NETWORK\ADMIN\SQLNET.ORA

7. If you are using domain names check your SQLNET.ORA file for the parameter

     names.default_zone=<world>. The domain name must be specified in the

    connect string if no parameter exists in the SQLNET.ORA file. In the case

    that you are not using domain names, then this parameter should be     commented out in your SQLNET.ORA file:

        #names.default_zone=domain

    If you comment out this parameter you must also remove the .world suffix

    in the SQLNET.ORA file and comment out:

        #names.default_domain=world

8. Check for multiple copies of your tnsnames.ora file. Also make sure that

    there are no duplicate copies of sqlnet.ora.

9. Add the TNS_ADMIN variable to the oracle.ini file and set it to the

    directory where tnsnames.ora and sqlnet.ora are located.

  1. An ORA-12154 can also result from bug #211512 - a problem with the file handlers being allocated. One symptom of this problem is that tracing for SQL*Net v2 cannot be turned on. The workaround for this problem is to close other Windows applications to allocate more file handlers. If you're using Microsoft Access, a possible workaround would be to ensure the application does not have a lot of objects and establish a connection. Afterwards, you may be able to establish a connection with an application with more objects.
  2. If you are connecting with Server Manager for Windows, it requires the use of the 'TNS:' prefix with the alias. Use the connect string below:

             TNS:ALIAS

  1. If you are getting ora-12154 when trying to activate a session using an application built on RDBMS 7.1.x libraries such as Oracle Power Objects, make sure you are using SQL*Net V2.1.x.
     Oracle Power Objects uses the 7.1 libraries and SQL*Net 2.0.x
     and V2.2 are not guaranteed to work with applications based on
     the 7.1 libraries.

  1. If you are getting ora-12154 when running a Power Objects application (standalone or runtime), and the same application works with Designer, then this may be bug 318008. Power Objects patch ver 1.0.16 provides a fix for this bug.
  2. If using Oracle Names, make sure you can connect to the Names server.
  3. Add the variable TNS_ADMIN to the Oracle folder in the registry.
Received on Wed Aug 12 1998 - 04:05:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US