Solved

Connecting 8i Client with Oracle 7release-7.1

Posted on 2001-06-20
8
990 Views
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.
0
Comment
Question by:alokkr99
8 Comments
 
LVL 3

Expert Comment

by:ubasche
Comment Utility

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.


0
 

Author Comment

by:alokkr99
Comment Utility
Hello,
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.
0
 
LVL 3

Expert Comment

by:ubasche
Comment Utility

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.

0
 
LVL 2

Expert Comment

by:payperpage
Comment Utility
You could try using net2 client?  Worked for me once.
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
LVL 2

Expert Comment

by:stmontgo
Comment Utility
can you tnsping the database from the client?

0
 
LVL 47

Expert Comment

by:schwertner
Comment Utility
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:

REKS816.RILA.us =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = bigbluenew.rila.us)(PORT = 1521))
    )
    (CONNECT_DATA =
      (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 TNSNAMES.ORA file

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  
"oas.this.com" in DNS. The connection is via TCP/IP to port 1521, and  
the SID of the database containing the server is V732.

oas =  
  (description=  
     (address=(protocol=tcp)(host=oas.this.com)(port=1521))  
     (connect_data=(sid=V732))  
  )  
 
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 "oas.this.com" will result in a final connect string of  
"conn.oas.this.com". It is this final value "conn.oas.this.com" that will be  
searched for in the TNSNAMES.ORA file; thus, your entry in the TNSNAMES.ORA
file should start with

conn.oas.this.com =  


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 2.3.3.0.0 - Production on 02-JUN-
97 18:39:09

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

Attempting to contact  
(ADDRESS=(COMMUNITY=tcp.oas.this.com)(PROTOCOL=TCP)(Host=
conn.oas.this.com)(Port=1521))
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  
database.

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 2.3.3.0.0 - 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
syntax:
       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 8.0.4.0.0 - Production on 15-AUG-99 08:03:
04

(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: tcp2.oas.this.com
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.

TNSNAMES.ORA
~~~~~~~~~~~~~
HOST = 196.6.122.28 or tcp2

Calling address: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(Host=196.6.122.28)(Port=1521))(ADDRESS=(PROTOCOL=TCP)

SQLNET.ORA
~~~~~~~~~~~
names.default_domain = oas.this.com
name.default_zone = oas.this.com

HOST File (WINNT/system32/hosts)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
196.6.122.28     tcp2.oas.this.com


Solution Description
--------------------

To correct the problem ensure the following:

TNSNAMES.ORA
~~~~~~~~~~~~
HOST = tcp2.oas.this.com

SQLNET.ORA
~~~~~~~~~~
names.default_domain = oas.this.com
name.default_zone = oas.this.com

HOSTS File
~~~~~~~~~~
196.6.122.28     oas.this.com

Explanation
-----------
The Calling address in the tnsnames.ora and host file has a different domain_name then in the sqlnet.ora
thus
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:

NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P1
You do the following:

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

Problem
=========
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
Password.

-  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.:

\\Servername\Sharename.

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.
         
0
 
LVL 54

Expert Comment

by:nico5038
Comment Utility

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.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER !

Nic;o)
0
 

Accepted Solution

by:
Jgould earned 0 total points
Comment Utility
Question has been closed as per recommendation

JGould-EE Moderator
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

This article describes some very basic things about SQL Server filegroups.
Entering a date in Microsoft Access can be tricky. A typo can cause month and day to be shuffled, entering the day only causes an error, as does entering, say, day 31 in June. This article shows how an inputmask supported by code can help the user a…
Video by: Steve
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
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…

763 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

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now