Ora 12154 error - database

I recently deploy one web application in one of my development servers. I'm using oracle, asp.net and c#. When I run the application in the server everything works fine, but when I try to run the application outside of the server (using my pc, for example) i get this error:
ORA-12154: TNS:could not resolve the connect identifier specified
If i run the application in my pc with visual studio it works fine.
Oracle is installed in Server "A" and the application is in server "B". Server "A" is in one domain and server "B" is in other domain.My pc is in the same domain has Server "A".
In my pc I can find the file tnsname.ora in C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN, but in Server "B" i canĀ“t find it anywhere
any idea?
Thanks for the help.

Have you tried this yet? (from http://ora-12154.ora-code.com/)
ORA-12154: TNS:could not resolve the connect identifier specified
Cause: A connection to a database or other service was requested using a connect identifier, and the connect identifier specified could not be resolved into a connect descriptor using one of the naming methods configured. For example, if the type of connect identifier used was a net service name then the net service name could not be found in a naming method repository, or the repository could not be located or reached.
Action:
- If you are using local naming (TNSNAMES.ORA file):
Make sure that "TNSNAMES" is listed as one of the values of the NAMES.DIRECTORY_PATH parameter in the Oracle Net profile (SQLNET.ORA)
Verify that a TNSNAMES.ORA file exists and is in the proper directory and is accessible.
Check that the net service name used as the connect identifier exists in the TNSNAMES.ORA file.
Make sure there are no syntax errors anywhere in the TNSNAMES.ORA file. Look for unmatched parentheses or stray characters. Errors in a TNSNAMES.ORA file may make it unusable.
If you are using directory naming:
Verify that "LDAP" is listed as one of the values of the NAMES.DIRETORY_PATH parameter in the Oracle Net profile (SQLNET.ORA).
Verify that the LDAP directory server is up and that it is accessible.
Verify that the net service name or database name used as the connect identifier is configured in the directory.
Verify that the default context being used is correct by specifying a fully qualified net service name or a full LDAP DN as the connect identifier
If you are using easy connect naming:
Verify that "EZCONNECT" is listed as one of the values of the NAMES.DIRETORY_PATH parameter in the Oracle Net profile (SQLNET.ORA).
Make sure the host, port and service name specified are correct.
Try enclosing the connect identifier in quote marks. See the Oracle Net Services Administrators Guide or the Oracle operating system specific guide for more information on naming.

Resolving TNS errors can be a real pain. A few things to keep in mind.
Most development environments (like visual studio) keep their own copy of the TNS connection information, and do not use the TNSNAMES.ora file. The file where this information is kept does not have to be called TNSNAMES.ora, that's just the default name. Which may be the reason you can't find it on Server B.
If you have the oracle client software (or an oracle database) you can use tnsping to check if your TNSNAMES.ora file is configured correctly.
The most frequent problems with a TNSNAMES.ora file configuration are using the wrong service name and/or using the wrong host name. You may need to change the "ODB_A" to "ODB_A.WORLD" or vice versa, depending upon the SQLNET settings. For Oracle 10, the latter is the default SQLNET setting. For the latter, you need to use ping to see server "A", and know if you need to use "SERVERA" or "SERVERA.DOMIN.COM" or an IP address.

Do not put # in the password you are setting or remove it from the password.
I was also getting the error and after changing it, the error got resolved.

Guess: An oracle client is not installed on Server B.
If you do have an oracle client installed then you can still put a tnsnames file in any location (Such as a directory on a network share). In order to do this, set a TNS_ADMIN system variable (System Properties->Advanced->Environment Variables on XP) to the directory containing your tnsnames files.
For me for example I have a system variable: TNS_ADMIN - C:\oracle\ora92\network\ADMIN

Is ORACLE_HOME set on server B?

It seems you need to install Oracle Client on "Server B" (the application server), and configure it's TNSNAMES.ORA file. This is required since otherwise, the running code will have no idea where to look for the database you use in the application (probably you're configured a data source in web.config or hard-coded something).
Remember - you cannot access Oracle (easily) without Oracle Client.

Had the same problem. Turns out the TNSNAMES.ORA in out deployment environment had a different ADDRESS_NAME and SID/SERVICE_NAME ,and the application was configured to use the SID - which caused the problem.
Your connection string must contain the ADDRESS_NAME and not the SID

Possible Resolutions -
Verify that the TNSNAMES.ORA exists and is accessible.
Make sure that there are no syntax errors in TNSNAMES.ORA.
Verify that the connection string is correct.
Verify if there are any DNS issues.
If the problem is while connect to server using PL sql developer client.try to install SQL developer within Program File instead of Program Files(x86)'s

Add the environment:
Variable Name: TNS_ADMIN
Variable Value: (YourDrive):\app\(UserName)\product\11.2.0\dbhome_1\NETWORK\ADMIN

I had faced the similar issue. The below code was working in my system but was not working in another server even though I had added a tns entry in tnsnames.ora file.
con = new OracleConnection();
con.ConnectionString = "User Id=username;Password=password;Data Source=uit45";
con.Open(); // throws error here
After digging and digging, I found out the solution for this. We need to ignore the entry in tns file and can be given tns entry as connection string, which worked fine for me. Try the below code.
con = new OracleConnection("Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-uit45.xxx)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SID=uit45)));User Id=username;Password=password");
con.Open();
Note that you need to give the associated values, especially for HOST,PORT,SID,User Id and Password.

Related

BULK INSERT error when the file location changed to remote share

I am getting following error on BULK INSERT after the file location was changed to remote share. Before it used to be a shared folder in local drive and we never ran into this issue. I am running this BULK INSERT from my local PC connecting to SQL Server via SSMS.
I have made sure both SQL server and file permissions are in place.
Before when I ran this command from SSMS, it was \\SQLServer\FTP location which was a shared folder in local drive in that SQL Server but now I changed the file location to a network share \\Fileshare\FTP and have the above error but both SQL service account (domain account) and me (domain account) have elevated permission on that new location.
Any help or suggestions!!
Thanks,
I can identify three circumstances that might generate this issue:
From the SQLAuthority Blog, full detail on a related backup issue where there is a cross-domain link (in this case, from a workgroup to a full domain).
There are also two other possible answers in the question Cannot bulk load because the file could not be opened. Operating system error code 1326(Logon failure: unknown user name or bad password.) here on StackOverflow. We can discount the first one (login permissions) because you stated that you had permissions, but the other solution (I fixed it by adding the SQL Server port number to the connection string in SSIS, forcing SSIS to access SQL Server through TCP/IP instead of Named Pipes.) could apply. Try forcing a connection to the server using TCP/IP.
All of these issues appear to be related to having an attempt at cross-domain communication. If this is the issue with you, one or more of these fixes should be applicable to your issue.
-
It finally worked....
I had to configure Kerberos Authentication following the guide from this link https://thesqldude.com/2011/12/30/how-to-sql-server-bulk-insert-with-constrained-delegation-access-is-denied/.
Of course, I had to make adjustments to suit our environment and had to involve Active Directory Admin for creating SPNs and enabling DELEGATION properties.
Thanks.

SQL Server Linked Server with tnsnames.ora on network share - ORA: 12154

Having an issue getting a SQL Server linked server to Oracle working while using a tnsnames.ora file on a network share.
If I copy the tnsnames.ora file to the local server, the linked servers work fine. However, we keep the file on a network share. My sql service accounts have read access to the share. I configure TNS_ADMIN system variable to the network share, the linked servers no longer work. I get ora-12154: could not resolve the connect identifier specified. tnsping and sqlplus work on the server. When I use process monitor to investigate further, I see:
Operation: createFile
Result: ACCESS DENIED
...
Impersonating: domain\MyLogin
This seems like an issue, but is maybe a false positive? If a process is trying to impersonate my account and access a remote resource it will fail since we don't have Kerberos configured to handle double-hop.
SQLPlus and TNSPing work just fine with the network share configured.
I've looked at this post and tried the items that seemed relevant, but had no success.
Additional Info:
sqlnet.ora has this:
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
I am able to open a file browser as a service account and open the tnsnames file.
I had this same issue while trying to connect a oracle 10g database via my WCF serivce developed in .NET 4.0 framework.
I was having multiple instances of ORACLE installed in my system. So, I modified the ORACLE_HOME to point to the Oracle 10g and it worked.
Also check the following:
Your service name might have an alias, so Make sure that your listener is listening for the same service name that you are using and check for both local and global entries. Check:
$ORACLE_HOME/network/admin/tnsnames.ora
Check your global_name setting with this SQL:
select * from global_name;
Also, Please make sure you add the Key TNS_ADMIN in the registry and create a enviroinment variable with name TNS_ADMIN
Regedit->HKEY_LOCAL_MACHINE->Software->Oracle->RightClick NEW->StringValue and name
Specify the correct path where the oracle is installed for Example
X:oracleproduct32bit10.0.1.0.0NETWORKADMIN
Edit
The below video also looks quite helpful. Please check.
https://www.youtube.com/watch?v=Sec8WG8gQPg
As an Oracle DBA I sometimes have to work with Windows. Maybe you can adopt from my experiences with Oracle on Windows.
Scenario:
An Oracle DB runs under a domain user. I want to restore a database from a backup which is located on a Windows share (sounds like "read" but it obviously isn't). I (or let's say the windows team) did not manage to find the proper way to grant the required permissions.
After many tries, the admins grant "everything" to the entire Oracle server.
Even though the Oracle process runs in a user context we did not find a set of permissions for the user only. Only the permissions for the entire server enabled the restore process to access the data.
From security point of view this is a horrible solution! But maybe it will help you to come closer to a solution (and if so, please share :-)).

Cannot bulk load because the file could not be opened. Operating System Error Code 3

I'm trying to set up a Stored Procedure as a SQL Server Agent Job and it's giving me the following error,
Cannot bulk load because the file "P:\file.csv" could not be opened. Operating system error code 3(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 4861)
Funny thing is the Stored Procedure works just fine when I execute it manually.
The drive P: is a shared drive on Windows SQL Server from LINUX via Samba Share and it was set up by executing the following command,
EXEC xp_cmdshell 'net use P: "\lnxusanfsd01\Data" Password /user:username /Persistent:Yes'
Any help on this would be highly appreciated
I do not know if you solved this issue, but I ran into the same issue. If the instance is local you must check the permission to access the file, but if you are accessing from your computer to a server (remote access) you have to specify the path in the server, so that means to include the file in a server directory, that solved my case.
example:
BULK INSERT Table
FROM 'C:\bulk\usuarios_prueba.csv' -- This is server path not local
WITH
(
FIELDTERMINATOR =',',
ROWTERMINATOR ='\n'
);
To keep this simple, I just changed the directory from which I was importing the data to a local folder on the server.
I had the file located on a shared folder, I just copied my files to "c:\TEMP\Reports" on my server (updated the query to BULK INSERT from the new folder). The Agent task completed successfully :)
Finally after a long time I'm able to BULK Insert automatically via agent job.
Best regards.
I have solved this issue,
login to server computer where SQL Server is installed get you csv
file on server computer and execute your query it will insert the
records.
If you will give datatype compatibility issue change the datatype for that column
Using SQL connection via Windows Authentication:
A "Kerberos double hop" is happening: one hop is your client application connecting to the SQL Server, a second hop is the SQL Server connecting to the remote "\\NETWORK_MACHINE\". Such a double hop falls under the restrictions of Constrained Delegation and you end up accessing the share as Anonymous Login and hence the Access Denied.
To resolve the issue you need to enable constrained delegation for the SQL Server service account. See here for a good post that explains it quite well
SQL Server using SQL Authentication
You need to create a credential for your SQL login and use that to access that particular network resource. See here
I would suggest the P: drive is not mapped for the account that sql server has started as.
It's probably a permissions issue but you need to make sure to try these steps to troubleshoot:
Put the file on a local drive and see if the job works (you don't necessarily need RDP access if you can map a drive letter on your local workstation to a directory on the database server)
Put the file on a remote directory that doesn't require username and password (allows Everyone to read) and use the UNC path (\server\directory\file.csv)
Configure the SQL job to run as your own username
Configure the SQL job to run as sa and add the net use and net use /delete commands before and after
Remember to undo any changes (especially running as sa). If nothing else works, you can try to change the bulk load into a scheduled task, running on the database server or another server that has bcp installed.
I did try giving access to the folders but that did not help.
My solution was to make the below highlighted options in red selected for the logged in user

How to override or workaround compiled DB connection info

I've faced a bit strange problem. There is a site client would like to duplicate on another domain name. Site is built on ASP(yes, old v1 ASP :( ) with SQLServer. Problem is that all the database operations, including connection information is compiled into a DLL library.
Is there a way to some how intercept, override or workaround this?
Platform:
Windows 2000 Server
SQLServer 7
ASP v1 (VisualBasic)
What a nightmare...
If you have control over the new database server, and the connection string references the database server by name, you could add a line in the hosts file which points the name of the old server to a new ip address. Then you still have to create a user with the same password on the new database server.
Yes! However, your new database name MUST be smaller or equal to the length of your old one. Simply open up the vb6 .dll in any Hex Editor and search and replace. Make SURE you do not change the length of the DLL or shift any bytes around.
Failing that, add a hosts entry to windows to redirect the connection.
Could it be that the application uses a DSN definition for the connection?
In Control Panel -> Administrative Tools open ODBC Data Source Administrator. Have a look at the System DSN tab. Does there seem to be anything listed there that is related to the application?
Before you hack your DNS or rename the server, be aware that the SQL Server client supports aliases specifically for this scenario: How to: Create a Server Alias for Use by a Client.
The SQL 2000 tool for configuring an alias is the Client Network Utility.
Do you have any configuration options at all from asp? Even dbname or the such? If so you might be able to use two separate servers for IIS and use a single db server. I'm afraid you might need to find the source or the guy who wrote it.
If you could figure out the connection string or DNS you might be able to do something.
You could write your own passthrough ODBC provider.

Change my local named SQL Instance from 'localhost\sql05' to just 'localhost'

I currently have a SQL Server 2005 instance installed on my local machine, and at the time of installation I named the instance 'localhost\sql05'
Can I easily change this to just 'localhost'
From what I can tell, the best option is to simply install the instance with the name you would like, move the DB's over, and then remove the instance you want to replace. While the link to CodeJournal seems promising, I don't believe it will yield positive results.
http://www.coderjournal.com/2008/02/how-to-change-instance-name-of-sql-server/
Also see this post (duplicate here on SO)...
https://stackoverflow.com/questions/907851/change-sql-server-instance-name
The only way to rename an instance is to uninstall it and re-install it under the correct instance name. Tricks that try to work around the name like creating an alias or making the named instance listen on the default port but they sometimes work sometimes don't, and they can fail in seemingly random manner, eg. due to the SPN (Service Principal Name) requested by the client during authentication.

Resources