This content has been marked as final. Show 10 replies
Also getting the same error with beta for VS 2005 on an XP-x64 system.
"An error occurred while opening the connection:
ORA-12154: TNS:could not resolve the connection identifier specified"
The connection fails with both the Oracle Explorer and the built-in Visual Studio Server Explorer (same reason/error).
Is the problem with all 64-bit Windows operating systems or is it just XP?
from metalink, don't use standard installation path and it's works:
ORA-12154: TNS:could not resolve the connect identifier specified
ORA-6413: Connection not open.
64-bit Microsoft OS's install 32-bit applications into the following location
"C:\Program Files (x86)\..."
rather than the typical location of
This causes an existing networking bug to occur where the networking layer is unable to parse program locations that contain parenthesis in the path to the executable which is attempting to connect to Oracle.
The following bug has been filed to correct this behavior:
Bug 3807408 CANNOT EXTERNALLY AUTHENTICATE USER WITH QUOTE IN USERNAME
The reason you receive an ORA-12154 vs. an ORA-6413 is generally due to which programmatic interface you have chosen to use to connect to Oracle.
The ORA-12154 is the typical error seen when connecting with up-to-date interfaces using the latest version of the Oracle Call Interface (OCI):
* Oracle ODBC Driver
* Oracle Provider for OLE DB
* Oracle Objects for OLE
* Oracle Data Provider for .NET (ODP.NET)
* Microsoft's .NET Managed Provider for Oracle
The ORA-6413 is typical of using older interfaces which make legacy API calls such as Oracle's OCI Version 7 API:
* Microsoft ODBC Driver for Oracle
* Microsoft OLE DB Provider for Oracle
To resolve this problem try either of the following solutions:
* Use a version of the Oracle client AND database software that contains the fix for Bug 3807408. This fix requires that both the client and database software be patched.
NOTE: Currently this bug has not been resolved. See SOLUTION 2 for now.
* Find the location of the application that is generating the error. Check the path to this location and see if it contains any parenthesis. If so, you must relocate the application to a directory without any parenthesis in the path.
I have a problem in connecting to oracle from VS 2005,
I am using Oracle 9i, VS 2005 in vista.
Initially my oracle was not working, i made required changes ("C:\Program Files (x86)\..." rather than the typical location of "C:\Program Files\...")
now i can connect to oracle server using oracle client.
but when i try connecting from VS 2005 error : ORA-12154: TNS:could not resolve service name is prompted.
can you pl help me in this.
I am using Oracle 9i (32bit in VISTA)
can any one help me in this
Hi, I figured I would reply to this message, as it took a ton of reading around to find a solution, and even then, no confirmation of success.
I am running ODT for VS (2005, .NET 2.0, 3.0) on a 64bit windows xp professional machine with visual studio installed to the default location (drive://program files(x86). I also have express 10 installed, and installed in a separate ora home from odt.
Anyhow, I couldn't get oracle explorer to connect, kept getting 12154 using tns names and another one 6513 when I used //machine:port/service. TNSPING would succeed (once I coped my tnsnames.ora from the oracle express admin folder to the ODT admin folder. Incidentally, setting up a TNS_ADMIN entry in the registry would work to -- in fact, I recco you do that prior to installing anything, and then both use it automatically.
Anyhow, to solve the error, on a 64 bit os, any application that is going to start and make use of oracle client MUST not be in a directory with a parenthesis in it (IE: "program files(x86)"). Now, it would be a pain in the rear to have to install visual studio and the 50000 other thing i have installed the reference it, so i came up with another solution:
I recalled that NTFS as of windows 2000 supports something similar to symbolic links on unix, called junctions. Essentially, you can make a low level alias to the program files (x86) dir to some other name, and then launch visual studio from there, and life is good.
Here is a tool for doing juntions, from the good folks (well, they were good, then microsoft sucked em up) at sysinternals: