Home » RDBMS Server » Networking and Gateways » TNS-12514 Message connecting from XP to Unix
| TNS-12514 Message connecting from XP to Unix [message #128220] |
Fri, 15 July 2005 15:03  |
MaynardGKrebs
Messages: 4
Registered: July 2005
Location: Kansas City
|
Junior Member |
|
|
Normally I don't post this sort of thing -- I do my research
and solve the problem myself, but I haven't been able to
resolve this. I've Googled, I've been to Oracle web pages,
I've racked my brain and tried everything I can think of.
I have two machines running Unix SVR4 (yes, I know that no one
uses SVR4 in 2005, but I'm stuck with them). On these machines
I have Oracle databases, version 8.1.5.0.0. I'm trying to connect to these d.b.s from my Windows XP machine. The version
of Oracle running on the XP machine is 9.2. In the path
\oracle\ora92\network\admin I have a "sqlnet.ora" file and a
"Tnsnames.ora" file. I copied these files from another Windows
XP machine, which is able to connect to the Unix databases. I
created a System DSN on my XP machine under the control panel,
administrative tools, data sources (ODBC). I was careful when
creating the System DSNs to specify the sqora32.dll file that
lives in \Oracle\ora92\bin.
I've looked this up in Oracle documentation, which says:
| Quote: |
TNS-12514 TNS:listener could not resolve SERVICE_NAME given in connect descriptor
Cause: The SERVICE_NAME in the CONNECT_DATA was not found in the listener's tables.
Action: Check to make sure that the SERVICE_NAME specified is correct.
|
The specified SID is correct. There's no service name on the
Unix machines because there is no tnsnames.ora files. I assume
this isn't necessary, since the other user's PC connects to the
Unix machines just fine; she pulls data from them every day.
Also when I get into SQLPLUS in Unix and type "show parameter service_names" I get:
ORA-00942: table or view does not exist
So I conclude that no service name exists in the Unix machines.
I've checked the listener.ora file on Unix, and looked at the listener.log file, and not found anything obviously wrong (or even helpful) in them. I'd put the listener.trc trace file up, except that it's 548 lines long, and doesn't seem to show any problems.
When I click configure on a DSN, then "test connection", I see:
ORA-12514: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
This is the same thing I see when I try to connect using SQLPLUSW.
The SID specified in the Tnsnames.ora file on my XP machine matches the SID that's used on the Unix machines.
The file \Windows\System32\drivers\etc\hosts defines the two
Unix machines and their IP addresses correctly. Their Data Source Names in the DSNs match the names used in the hosts file.
The TNS service name in the DSNs matches the names in Tnsnames.ora file (which I've spelled the same as in the hosts file).
I found this in the /oracle/dbs/initA.ora file the line:
service_names = intuity.local.db
I added this to the Tnsnames.ora file on my XP machine. It didn't
help.
I also tried connecting using no service name at all. This didn't
help, either.
I also tried four different community names.
At the bottom are my sqlnet.ora file and Tnsnames.ora file from
the XP machine, edited for purposes of brevity and security.
Furthermore, "tnsping" works. I realize this doesn't actually go
as far as the SID, but at least it proves some connectivity.
Also, when I turn off the listener on one of my Unix machines
and try to connect to it, I get this instead:
ORA-12541: TNS:no listener
So my configurations aren't entirely haywire -- they at least detect
correctly that Oracle is up and running (or not) on the Unix boxes.
Again, when trying to connect using SQLPLUSW instead of using the
"test connection" on the DSN, the result matches the "test connection".
At one point, months ago, I actually had this working for one day, and the next day it spontaneously broke (the very next day!). Because my company planned to upgrade my PC, I held off working on it until now. I'm going through the same trauma I went through the first time, except that I haven't been able to get it working.
I've tried replacing the sqora32.dll with an 8.2 version, but it
wouldn't run (popped up a box that complained), so I had to restore the correct version.
Could the problem be that XP is trying to connect using service
names, while Unix is using SIDs? I thought that the line
(CONNECT_DATA = (SID = A))
in the XP file Tnsnames.ora would get around this difficulty.
Could the problem be an incompatibility between the Oracle versions on XP and Unix?
Or am I missing something in one of the .ora files?
Is there some environment variable I need to set in XP?
(The only thing in the environment that has "ora" in it is PATH.)
Can anyone suggest what's wrong, and how to fix it?
sqlnet.ora file:
AUTOMATIC_IPC = ON
TRACE_LEVEL_CLIENT = OFF
SQLNET.EXPIRE_TIME = 0
NAMES.DEFAULT_DOMAIN = our_domain.com
NAME.DEFAULT_ZONE = our_domain.com
SQLNET.CRYPTO_SEED = "[removed for security]"
NAMES.DIRECTORY_PATH = (HOSTNAME, TNSNAMES)
Tnsnames.ora file:
IVR1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = TCP.world)
# (COMMUNITY = Our_community.com) Tried this
# (COMMUNITY = tcp.Our_community.com) Tried this
# (COMMUNITY = na.ad.our_corp.com) Tried this
(PROTOCOL = TCP)
(Host = www.xxx.yyy.zzz)
(Port = 1521)
)
)
(CONNECT_DATA = (SID = A)
)
)
IVR2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = TCP.world)
# (COMMUNITY = Our_community.com)
# (COMMUNITY = tcp.Our_community.com)
# (COMMUNITY = na.ad.our_corp.com)
(PROTOCOL = TCP)
(Host = www.xxx.yyy.aaa)
(Port = 1521)
)
)
(CONNECT_DATA = (SID = A)
)
)
Script capture of "lsnrctl status"
Script started on Fri Jul 15 13:38:24 2005
Machine2> script /tmp/ivr2.15Jul2005.lsnrtcl.txt
Machine2> lsnrctl status
LSNRCTL for Intel SVR4 UNIX: Version 8.1.5.0.0 - Production on 15-JUL-05 13:38:27
(c) Copyright 1998 Oracle Corporation. All rights reserved.
Connecting to (ADDRESS=(COMMUNITY=TCP.world)(PROTOCOL=TCP)(HOST=Machine2)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Intel SVR4 UNIX: Version 8.1.5.0.0 - Production
Start Date 26-MAY-05 12:21:55
Uptime 50 days 1 hr. 11 min. 36 sec
Trace Level admin
Security OFF
SNMP OFF
Listener Parameter File /oracle/network/admin/listener.ora
Listener Log File /oracle/network/log/listener.log
Listener Trace File /oracle/network/trace/listener.trc
Services Summary...
A has 1 service handler(s)
A has 2 service handler(s)
The command completed successfully
Machine2> ^D
script done on Fri Jul 15 13:38:30 2005
listener.ora file from one of the Unix machines:
############
# Filename : listener.ora
# Name : server name
# Date : Thu Apr 12 08:33:50 EDT 2001
#############
LISTENER =
(ADDRESS_LIST =
(ADDRESS=
(COMMUNITY = TCP.world)
(PROTOCOL = TCP)
(HOST = name_of_this_machine)
(PORT = 1521)
)
)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 10
TRACE_LEVEL_LISTENER = ADMIN
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = A)
)
) |
|
|
|
|
|
|
|
| Re: TNS-12514 Message connecting from XP to Unix [message #128577 is a reply to message #128458] |
Tue, 19 July 2005 08:32  |
Frank Naude
Messages: 4579
Registered: April 1998
|
Senior Member |
|
|
OK, the second change I would make is to fully specify the connect descriptors in your TNSNAMES.ORA file. For example:
IVR1.our_domain.com =
(DESCRIPTION =
(ADDRESS_LIST =
...
The "our_domain.com" part is defined in your SQLNET.ORA file.
If you want, you can remove "(COMMUNITY = TCP.world)" as it doesn't do anything.
Also, do a ping of the (HOST=???) portion to see if it resolves to the same machine you have the database on:
It might also help to extract the SQLNET.ORA and TNSNAMES.ORA from the working PC and copy it to your machine. Find all occurrenses on your machine, as these files might be located in several directories.
Best regards.
Frank
|
|
|
|
| Re: TNS-12514 Message connecting from XP to Unix [message #128796 is a reply to message #128220] |
Wed, 20 July 2005 12:16 |
MaynardGKrebs
Messages: 4
Registered: July 2005
Location: Kansas City
|
Junior Member |
|
|
I tried all of these things, too. I made the suggested edits in tnsnames.ora. I'd already pinged, but did so again. And I'd already copied the files over from the machine that's working.
The idea about looking for other .ora files was a good one, and it occurred to me that maybe they weren't in the PATH. I started a DOS window and typed PATH. Sure enough, the directory with the .ora files wasn't in the path, so I copied the files to an Oracle directory that was in the path. This didn't fix the problem either.
I'm at wit's end.
|
|
|
|
| Re: TNS-12514 Message connecting from XP to Unix [message #129019 is a reply to message #128796] |
Thu, 21 July 2005 10:06 |
 |
Mahesh Rajendran
Messages: 10707
Registered: March 2002
Location: oracleDocoVille
|
Senior Member
Account Moderator |
|
|
Just a few thoughts.
first
--
-- There is a difference between versions.
-- in line 7
-- to talk to 8i (815/816/817) database use SERVICE_NAME
-- for a 9i database or 805 and below use SID=sample in line 7
--
line1 SAMPLE =
line2 (DESCRIPTION =
line3 (ADDRESS_LIST =
line4 (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521))
line5 )
line6 (CONNECT_DATA =
line7 (SERVICE_NAME = sample)
line8 )
line9 )
second,
>>SQLNET.CRYPTO_SEED = "[removed for security]"
and you are use sqlnet encryption.
If they are not matching. You wont be able to make the connection.
check that!.
[Updated on: Thu, 21 July 2005 10:08] Report message to a moderator |
|
|
|
| Re: TNS-12514 Message connecting from XP to Unix [message #129519 is a reply to message #129019] |
Mon, 25 July 2005 10:16 |
MaynardGKrebs
Messages: 4
Registered: July 2005
Location: Kansas City
|
Junior Member |
|
|
I've tried getting rid of the cryptography seed (commenting out the line), but this didn't work -- naturally, since the user who is connecting has this set in her configuration.
Also, I've tried using SERVICE_NAME instead of SID, guessing at what the service name would be, since I have no idea where to find it. This didn't help, either.
I really appreciate the help, but I have the feeling that there may be something very basic I'm overlooking. What baffles me is that this did work briefly, on my machine back in March, and then broke the very next day. (I thought this might have to do with DHCP, but my machine is still using the same IP address I added to /etc/hosts on the Unix servers.) Even more baffling, it works for the other user, and I started with copies of her .ora files.
|
|
|
|
|
|
Goto Forum:
Current Time: Wed May 15 17:46:08 CDT 2024
|
] 
Blog
Search
Help
Members
Register
Login
Home
