Connecting 8i Client with Oracle 7release-7.1

Posted on 2001-06-20
Last Modified: 2008-03-04
Hello Friends ,
at one of my client sites i am trying to connect Oracle Client 8i with Oracle7 release7.1 ,using NET8  easy config.utility.I am not able to connect The error i am getting is ORA-01034 (Oracle Not available
It is checked that Oracle is running listener is ON at Port-1526.

What could be the probable cause of this problem??
Or is it not possible to connect Oracle 8i (8.1.5)client
with Oracle 7 Realease 7.1
can anybody guide me in this regard.
Question by:alokkr99
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 6209803

There is no problem to connect a Oracle 8i client to a Oracle 7 database.

If the listener is running on port 1526 you have to make sure that your TNS names string also uses port 1526.

When running the easy config utility change the standard port (1521) to 1526 when creating a connect string.

Alternativly you can edit the tnsnames.ora file. It is located in $ORACLE_HOME/network/admin. $ORACLE_HOME depends on in which directory you did install your Oracle client software.


Author Comment

ID: 6210130
Thanx ,But i have done all this at unix at Oracle_home is /oracle/oracle i have checked all these prilims. issues
still i am having the same problem.

Expert Comment

ID: 6210266

I guess you can connect from the database server by typing
> sqlplus user/passwd
Do you get the same 1034 error when you try following on the database server
> sqlplus user/passwd@database

Did you get only the ORA-1034 without any other errors?

When there is no other error, it might mean there is a typo in the listener.
Even if the listener starts ok. Try to retype the listener.ora, there may be a
hidden character that is causing the problem. And restart the listerner afterwards.

I discovered a positing with a similar problem. It said that the database name
is case sensitive in Oracle 8. Make sure that you have case agreeement between the
instance_name and SIDS in the listener.ora and tnsnames.ora files. I don't know
if it will resolve your problem, but I guess it's worth a try.

Do you have a plan for Continuity?

It's inevitable. People leave organizations creating a gap in your service. That's where Percona comes in.

See how relies on Percona to:
-Manage their database
-Guarantee data safety and protection
-Provide database expertise that is available for any situation


Expert Comment

ID: 6212236
You could try using net2 client?  Worked for me once.

Expert Comment

ID: 6219299
can you tnsping the database from the client?

LVL 48

Expert Comment

ID: 6221206
You can use the "Oracle Net 8 assistant", "Oracle Net 8 Easy config" to see if you have the appropriate entry to the server in the local tnsnames.ora file (find it!). I mean that one in the Forms&Reports home, not that one in the Oracle_Home.
Under local I mean the file tnsnames.ora  in your application, not at the Oracle Server - this is a common mistake.

You have to have there an entry like: =
      (ADDRESS = (PROTOCOL = TCP)(HOST = = 1521))
      (SERVICE_NAME = REKS816)

It is a bad practice, but you can add such entry using simple text editor. But before that make a copy of tnsnames.ora in order to restore it if you do not succeed.

After that go to "control panel" and run "services".
Look at your Oracle_Home_TNSlistener80 process. Stop it! Start it again!

If you work on Unix find the relevant processes and notions of the Unix OS.

Two common areas of misconfiguration are responsible for these log-in errors:

(1) Erroneous entries in the TNSNAMES.ORA file, and  
(2) An erroneous default domain setting in the SQLNET.ORA file

A successful client log-in requires that:

1. The database is running.
2. The listener on the host machine is running and is configured correctly.
3. The network is correctly routing TCP/IP packets.
4. The client machine has TCP/IP installed correctly.
5. The client machine has SQL*Net installed correctly.
6. The TNSNAMES.ORA entry for that connection has the correct information.
7. The SQLNET.ORA file is configured correctly.

This solution covers common SQL*Net misconfiguration issues on the client side, and assumes that all
other necessary aspects of the connection are correctly configured and operating properly.

Please refer to the attached files for configuration information.



The log-in dialog box of the client asks for a connect
string to identify the database in which the client account is located.
The TNSNAMES.ORA file is then searched for this connect string, and the actual  
connect information is found.

Below is a sample TNSNAMES.ORA entry for connecting to a machine named  
"" in DNS. The connection is via TCP/IP to port 1521, and  
the SID of the database containing the server is V732.

oas =  
Note: the parentheses are extremely important - omitted or extraneous  
parentheses will result in an invalid entry. On the other hand, white space,
such as tabs, spaces, or newlines, are ignored.

The "host=" entry shown above implies DNS availability; if DNS is not
available, the IP address number may be substituted.

The SQLNET.ORA file:

Before being searched for in the TNSNAMES.ORA file, the connect string  
supplied in the log-in dialog box may be modified if the NAMES.DEFAULT_DOMAIN
variable has a value.

During login, the connect string is parsed to determine whether or not it is
fully-qualified, i.e. that it has full domain information. If it does not, and
the NAMES.DEFAULT_DOMAIN variable is set, then that value is appended to the  
connect string.  

For example, using a connect string "conn" and a NAMES.DEFAULT_DOMAIN  
setting of "" will result in a final connect string of  
"". It is this final value "" that will be  
searched for in the TNSNAMES.ORA file; thus, your entry in the TNSNAMES.ORA
file should start with =  

Using the TNSPING utility to test connect strings:

To test whether or not a connect string is valid, the utility TNSPING is
provided in the $ORACLE_HOME\bin directory. Run TNSPING with the connect
string you wish to test.  

Example 1:

D:\ORAWIN95\BIN>tnsping test

TNS Ping Utility for 32-bit Windows: Version - Production on 02-JUN-
97 18:39:09

Copyright (c) Oracle Corporation 1995.  All rights reserved.

Attempting to contact  
OK (170 msec)

<end example>

From this result, we see that the connect string "test" resolves correctly to
an entry in the TNSNAMES.ORA file to valid connect information for an Oracle  

On the other hand, the following is a test of an invalid connect string:

Example 2:

D:\ORAWIN95\BIN>tnsping notgood

TNS Ping Utility for 32-bit Windows: Version - Production on 04-JUN-
97 09:13:32

Copyright (c) Oracle Corporation 1995.  All rights reserved.

TNS-03505: Failed to resolve name

<end example>

Using TNSPING as a test ensures that your TNSNAMES.ORA entry syntax is
correct, and that there is a listener on the host machine listening for
requests for that port.

~~~~~     ~~~~~     ~~~~~     ~~~~~     ~~~~~     ~~~~~     ~~~~~     ~~~~~     ~~~~~     ~~~~~

What follows here are several common problem descriptions & their solutions.

Problem Description:
       You receive an ORA-12162 "TNS:service name is incorrectly
specified" when attempting a Sqlplus (804)/Net8 login with the following
       sqlplus <userid>@<alias>
Enter password: <password>

Problem Explanation:
Due to a parsing error with Sqlplus (8.0.4 only) the connect descriptor
is not beeing read properly.

Parsing error does not occur using other utilities, ie. tnsping,
svrmgrl or other versions of Sqlplus.
Using the tnsping utility you are able to resolve the connect string
and verify a listener process is responding.

For example:

[Alpha]> tnsping N804

TNS Ping Utility for Solaris: Version - Production on 15-AUG-99 08:03:

(c) Copyright 1997 Oracle Corporation.  All rights reserved.

Attempting to contact (ADDRESS=(PROTOCOL=TCP)(Host=Alpha)(Port=1521))
OK (60 msec)

Solution Description:
Try using a full command line syntax for Sqlplus to avoid this parsing
problem.  For example, at the command prompt use the following syntax:

         sqlplus system/manager@N804

Versus the previous syntax where you were prompted for the password:

       sqlplus system@N804
Enter password: manager    <password is not visible when using this syntax>

If you are able to connect with using the full line syntax, you are
running into Base Bug:611696 for Sqlplus Version 8.0.4.  This bug is fixed in Sqlplus
release 8.0.5, and serveral backports are available, depending on you platform.

Problem Description

TNSPING works fine but connecting via SQL*PLUS fails with an ORA-12545. Normally this indicates some

syntax issue with the TNSNAMES.ORA which is not the cause.

Turn on client tracing in the sqlnet.ora file TRACE_CLIENT_LEVEL = 16

nscall: connecting...
nsc2addr: entry
nttbnd2addr: entry
nttbnd2addr: port resolved to 2929
nttbnd2addr: looking up IP addr for host:
nttbnd2addr:  *** hostname lookup failure! ***
nttbnd2addr: exit

The problem in this case the tnsnames.ora, sqlnet.ora and hosts file had the following entries that
caused the the
lookup of the IP addr to fail when resolving the address in the host file.

HOST = or tcp2


names.default_domain =
name.default_zone =

HOST File (WINNT/system32/hosts)

Solution Description

To correct the problem ensure the following:


names.default_domain =
name.default_zone =


The Calling address in the tnsnames.ora and host file has a different domain_name then in the sqlnet.ora
causing ORA-12545.

Problem Description

The connection is refused. You know that the user exists and the password is
correct and the database is up.

You cannot connect from sql*plus on the client to your database. You get
the following error message;

ORA-12705 Invalid or unknown NLS parameter value specified.

Solution Description

Check your NLS_LANG settings.
The value entered is incorrect or there is a typo error.
For example, the NLS_LANG value for the United States English should be:

You do the following:

Create domain user accounts on Windows NT using Windows scripting, Enterprise
Administrator, or a third party administration tool.

Certain users cannot authenticate successfully with any Oracle OLAP client
product, such as Express Spreadsheet Add-in (XSA), Express Admininstrator, or
Express Analyzer (OEA), but can authenticate successfully using the Express
Connection Utility if they do the following:

-  Open the Express Connection Utility.

-  Select Options...Set Domain Identity, and enter the User ID, Domain, and

-  Select Options...Set Authentication Level, and choose Connect.

-  Select File...Open, choose Connect to remote Express Server 5 or 6, and
enter the following information:

Object UUID:    <Your OES UUID>
Transport:      ncacn_ip_tcp
Host:           <Your host name>

Solution summary
In User Manager for Domains, check the Profile for the failing user and make
sure the Home Directory does not have a UNC address specified in the "Local
path:" field.
Authentication failure can occur if Oracle Express Server is not able to get a
valid Home Directory.  This can occur if, in the Windows NT User Environment
Profile, Home Directory groupbox, the "Local path:" option is chosen, but a UNC
path is referenced in the field, e.g.:


Only a local path on the machine is valid for this field.

You can check this by doing the following:

-  Login to the Domain Controller as an Administrator.

-  Run the User Manager for Domains utility in the Administrative Tools.

-  Double-click on a failing user to open the User Properties dialog box.

-  Click on the Profile button.

If the "Local path:" option is selected in the Home Directory groupbox,  a UNC
path such as \\Servername\Sharename is not valid.

Normally, if you select the "Local path:" option and try to enter a UNC path,
you will get an error message as follows:

\\Servername\Sharename is an invalid path name.  Please enter a valid path name.

If you are using Windows scripting or an administration tool such as Enterprise
Administrator to create user accouts, it may be possible to create a user
profile with an invalid UNC path in the "Local path:" field.
LVL 54

Expert Comment

ID: 7257284

No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
 - PAQ'd and pts removed
Please leave any comments here within the
next seven days.



Accepted Solution

Jgould earned 0 total points
ID: 7282233
Question has been closed as per recommendation

JGould-EE Moderator

Featured Post

Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Using SQL Scripts we can save all the SQL queries as files that we use very frequently on our database later point of time. This is one of the feature present under SQL Workshop in Oracle Application Express.
When table data gets too large to manage or queries take too long to execute the solution is often to buy bigger hardware or assign more CPUs and memory resources to the machine to solve the problem. However, the best, cheapest and most effective so…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…
This is a high-level webinar that covers the history of enterprise open source database use. It addresses both the advantages companies see in using open source database technologies, as well as the fears and reservations they might have. In this…

729 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question