I'm trying to link SQL Server 2005 to an Oracle 10g database. I've installed the Oracle client on the SQL server and validated that I can connect to the Oracle database using both tnsping and sqlplus. When I try to run a query in SQL Server I get the following:
OLE DB provider "OraOLEDB.Oracle" for linked server "ORA_CSSA2APD" returned message "ORA-12154: TNS:could not resolve the connect identifier specified".
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "OraOLEDB.Oracle" for linked server "ORA_CSSA2APD".
Any ideas? I've tried both of the following queries with no luck:
select * from openquery(ORA_CSSA2APD, 'select count(rowid) from eservice_op.agent')
select count(rowid) from ORA_CSSA2APD..eservice_op.agent
I suspect an environment setting. That is, your session is picking up the TNSNAMES.ORA file but the session underlying SQL Server is not. I'd check were ORACLE_HOME and, possibly, TNS_ADMIN are being set and pointing to.
Are you able to use the easy connect syntax for the database with the SQL Server connection .
IE replace ORA_CSSA2APD with hostname:1521/service_name
ORA:12154 generally means that the alias of the db you're trying to connect to wasn't found in the tnsnames.ora file. (See http://ora-12154.ora-code.com/ a more detailed explanation.)
You need to make sure that the Data Source is an alias that the tnsnames file knows about (on the server where SQL Server resides, regardless of where you're running the queries from); SQL Server is going to be just like any other Oracle client and needs to know where to connect to and without the tnsnames.ora file, it's not going to know the details of where the Oracle db is.
If you don't have access to the SQL Server server (there's one from the department of redundancy department), you'll need to get the server admin to set that up for you.
(The Data Source property of the linked server should be the alias in tnsnames.ora alias for the db you're trying to link to.)
HTH...
TNS error messages generally means the connection is flawed (eg host is unobtainable/timesout on the specified port, or that is simply doesn't know what ORA_CSSA2APD is supposed to point to).
One thing to consider is, are you using a 64-bit Windows and are you using a 32-bit or 64-bit Oracle client (or possibly both). If you've got a 32-bit app running on a 64-bit OS trying to call Oracle, it needs a 32-bit Oracle client. Using a 32-bit client on a 64-bit OS can be tricky and it is safer to NOT install it in the "Program Files (x86)" folder.
Also bear in mind the following
In a 64-bit version of Windows Server
2003 or of Windows XP, the
%WinDir%\System32 folder is reserved
for 64-bit applications. When a 32-bit
application tries to access the
System32 folder, access is redirected
to the following folder:
%WinDir%\SysWOW64
So for 64-bit windows, the 32 bit stuff is in the SysWOW64 folder and the 64 bit stuff is in the system32 folder.
This issue happened to me, as well, but only with certain Windows user accounts. A combination of enabling the "Allow inprocess" provider option for the OraOLEDB.Oracle provide (SSMS > Server Objects > Linked Servers > Provides > OraOLEDB.Oracle), restarting the SQL Server Windows service and lastly adjusting the permissions on the TNSNAMES.ora file directly.
We found that SQL Server, for some unknown reason, started looking for the TNSNAMES.ORA file in default Oracle locations.
We were able to place the TNSNAMES.ORA files in the following locations, with successful results:
For SQL Server 32-bit on 32-bit OS or 64-bit on 64-bit OS
%ProgramFiles%\Oracle
%ProgramFiles%\Oracle\network\admin
For SQL Server 32-bit on 64-bit OS
%ProgramFiles% (x86)\Oracle
%ProgramFiles% (x86)\Oracle\network\admin
We too were able to connect using SQL*Plus, but SQL Server could not. It is important to note that SQL*Plus did not use the same TNSNAMES.ORA file. This is why one worked.
Related
I need to connect to a remote database (Oracle) using a MS SQL Server (2019) linked server. What I did so far:
Installed Oracle Instant Client x64 and the ODBC drivers on the machine where the SQL server is running
Created a symlink to the central TNSNAMES.ORA (on a file share in the network) inside the Oracle Instant client folder.
Set the necessary environment variables
Created an ODBC connection to the database on the Oracle server on this machine
Restarted MS SQL Server
Created a linked server (Microsoft OLEDB Provider for ODBC Drivers) in the SQL instance
When connecting to the SQL Server using sqlcmd on this machine (I did not install SSMS there), I can query the linked database using OPENQUERY(). I can also read the file TNSNAMES.ORA using this command (note, the given file is the symlink, but it displays the contents of the linked file, as it should):
SELECT * FROM OPENROWSET(BULK 'C:\InstantClientx64\tnsnames.ora', SINGLE_CLOB) TNSNames
So far, everything is fine.
Now, when I connect to the SQL Server from my workstation using SSMS, i get the following error when trying to read TNSNAMES.ORA using the command above:
Cannot bulk load because the file "C:\InstantClientx64\tnsnames.ora" could not be opened. Operating system error code 5(Access is denied.).
I created a file test.txt in the instant client folder containing something like "Am I allowed to read this?" - and I was, no problems.
I started procmon on the server to find out what happens. When using the above command on the SQL server, I get a REPARSE (because it's a link!), and then SUCCESS, the file is displayed in the sqlcmd console.
When using this command in SSMS (on my local workstation), first appears the REPARSE (OK), then ACCESS DENIED.
In both cases it is the same user account which is displayed as "Impersonating" in the procmon's details. There is definitely no problem with a firewall, and the read permissions on the tnsnames.ora file on the network share are granted for Everyone. I am also able to create an ODBC item on the local workstation, and can connect and query the database from here.
I have done this in the past I don't know how often, and never had problems. What am I missing?
Why are you trying to read the tnsnames.ora file via SQL? The Oracle libraries will (should) internally open it and use it when your app connects to the DB.
The default location for network config files is shown in the Instant Client installation doc. In your case it will be C:\InstantClientx64\network\admin. Unless you have set the TNS_ADMIN variable, then start by creating this subdirectory and putting tnsnames.ora in it.
(A future version of Instant Client on Windows will create the network\admin subdirectory automatically, similar to the way it is created with the Linux Instant Client packages).
I have an SSIS package where Source: IBM DB2, Target: SQL Server.
I have created a package in SSIS and able to run perfectly in my local machine. All connections work perfectly, data populates in the target tables.
However, after deploying it to SQL Server the package fails with following error in screenshot. Checked the server it has IBM OLEDB drivers for DB2 installed in it. Please help me out.
Your error message shows:
SQL1031N The database directory cannot be found on the indicated file
system.
This is not a programming matter, it is only configuration. The message means that the configuration (of the Db2 product on your SSIS hostname) is either not yet started, or has not yet been finished.
You can do the configuration with either a GUI, or via command-lines.
This work must be done on the hostname where the data-source is required (e.g. on the SSIS environment).
For a GUI: Use remote desktop to that SSIS environment, and then use the odbcad32 tool. Notice that there can be both a 32-bit version and a 64-bit version of odbcad32, so use the correct bitness to match the SSIS and Db2-driver bitness. Use odbcad32 to create and configure the data-source for the Db2-database. Usually that means creating and configuring a System data source. You can also test connectivity to the DSN from within odbcad32. The act of using odbcad32 to create the data source will (under the covers) cause the Db2 "database directory" to be created.
You can also do this configuration via either command-line actions (if the relevant Db2 tools are on the PATH, see db2 catalog tcpip node , db2 catalog database, db2 catalog system data source commands ), or alternatively by populating an XML file called db2dsdriver.cfg(which the Db2 driver interprets at runtime). All of these commands and configuration files are fully described in the free Db2 Knowledge Centre online.
I have been creating an access database for my assignment. I am using SQL Server 2014 for the datasource for the access tables. Now the problem is that according to the assignment
I need to make the db multiuser over network
it has to be an accde file
In short, how can I connect to SQL Server when I deploy the database on my college pc. And how to make the accde work on my school network where the SQL Server is not the one I am using at my personal machine.
It is a simple book entry database containing few tables including print button and picture of book attachment.
Use a DSN-less connection. Provide a function that changes the connection string on all linked tables.
See Linked table ms access 2010 change connection string
or Changing SQL connection information for DSN-less Access frontend
You don't want each user having to enter the server information into the frontend. So take your frontend to the school network, run the function to re-link all tables, then create the .accde, then distribute it.
If the sql server is on your same network, then all you have to do is link your tables to the production sql server. You then crate the accDE, and that can be deployed to any machine.
Access by “default” creates a DSN less connection. So if you follow the defaults when linking to sql server (use a FILE dsn), then once access links to those tables, access “converts” the DSN to a DSN less connection for you.
What this means is that you do not need any VBA re-linking code. When using a file dsn, access converts these to DSN less for you. Once linked, then Access ignores and does not use nor require the original DSN.
So your steps are:
Linking to the production SQL server on the network. Just make sure you use the “default” file dsn.
Once you are sure the accDB works with that production SQL server, you can then compile/create the accDE. That accde will now function on ANY workstation (and this work since access by default creates and uses and makes a DSN less connection for you).
You do NOT need any VBA re-link code.
You do NOT have to write some VBA code to create a DSN less connection (access does this automatic for you).
Of course, during this re-link process, your computer will have to be on the same network with the production SQL server you plan to link to.
If you were some off site worker, and you cannot be on the same network during the re-link process, then YES you would have to adopt some VBA code to re-link for you. However, if you can be on the same network during this re-link process, then at that point you can create the accDE file, and it can be distributed to any workstation on that network without further configuration.
About the only issue would be to ensure that you link to this production server using the standard and legacy “SQL Server Driver” as your linking choice. You can use the later “native 11” etc. drivers, but they are not installed by default on each version of windows and thus this ODBC driver may well not be installed on each workstation (but the standard SQL Driver is installed by default.
Again:
You do not need some VBA code or re-link code to create a DSN-less connection. Access by default when choosing a “file” DSN will create DSN-links for you – you thus don’t need any special re-link code, nor do you need some VBA re-link code to achieve DSN-less links.
Using SSIS for SQL Server (2012 or later) Standard Edition, I want to connect to a remote Oracle database using Windows authentication.
In my tests, this works fine when using sqlplus:
sqlplus /#MyRemoteConnection
In SSIS (using either ADO.NET or OLE DB Connection Managers), the connection
succeeds when specifying the user id and password.
The connection fails when specifying the "/" user (without a password) in the SSIS connection.
Is authentication through Windows supported at all for SSIS connections to Oracle?
If yes, how do I do this?
If Windows authentication is not supported, are there other tools which allow me to connect from SQL Server Standard Edition (that's why e.g. Attunity cannot be used)?
All suggestions are highly appreciated!
Yes, Windows authentication from SQL Server Standard Edition to Oracle is supported.
A valid ADO.NET connection string (e.g. using Visual Studio (SSIS), or the Import Wizard in SQL Server Management Studio) may look like this:
Data Source=<host name>:<port number>/<database name>;Integrated Security=SSPI;
An example:
Data Source=my_host_name.com:1521/ORCL;Integrated Security=SSPI;
For Windows Authentication, "Integrated Security"
needs to be set to "yes", "True" or "SSPI".
A valid OLE DB connection string looks like this:
Data Source=<host name>:<port number>/<database name>;User ID=/Provider=OraOLEDB.Oracle.1;
Example:
Data Source=my_host_name.com:1521/ORCL;User ID=/Provider=OraOLEDB.Oracle.1;
Please note:
The port number is optional and can be omitted if the standard port number (normally 1521) is used.
When using SSIS, the Connection Manager may complain with the message
"The given path's format is not supported."
This happens if the port number is specified in the connection string.
The connection string (including the port number) will work nevertheless, if the connection string is filled by a variable in an expression.
Further requirements:
On the file system (both on the client and the server), there has to exist a file sqlnet.ora.
This file has to contain the string
SQLNET.AUTHENTICATION_SERVICES= (NTS)
On the database server, and when using a full Oracle client,
the file sqlnet.ora should be located in the ORACLE_HOME\Network\Admin directory.
ORACLE_HOME normally is defined in the registry, under
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
If an Instant Client has been installed, the file sqlnet.ora can be put in the "network\admin" subdirectory under the directory where the Instant Client is located.
Please note that the Instant Client will not look into the registry to use (or evaluate) ORACLE_HOME.
Therefore sqlnet.ora files located there won't be read when trying to connect to the Oracle server!
(That's the reason why my connections failed all the time.)
Another option is to specify a directory for sqlnet.ora by setting the environment variable TNS_ADMIN, e.g. in the Windows Control Panel.
Example:
TNS_ADMIN=C:\TNS_ADMIN
Then, put the file sqlnet.ora into this directory.
On the Oracle server, the Windows user needs to exist.
Example:
create user "OPS$MYDOMAIN\MY_USER_NAME" identified externally;
grant create session, alter session to "OPS$MYDOMAIN\MY_USER_NAME";
(additional privileges may be required.)
Then it should be possible to connect to Oracle as Windows user MY_USER_NAME,
using Windows Authentication.
My machine is a macbook pro. However, my company's data is in SQL Server. In order to access it, I need to use VMWare Fusion to run SQL Server Management Studio 2008 on Windows XP.
When I attempt to run a bulk import (via instructions from SQLAuthority.com), I get this error:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "H:\test.CSV" could not be opened. Operating system error code 3(The system cannot find the path specified.).
I am dealing with 3 different file locations, but none of them work.
My Mac storage - "/Users/Admin/Documents/test.CSV"
My Windows XP storage - My "C:" drive. "C:\test.CSV"
My company's network location - Mapped to the "H:" drive via Windows XP. "H:\test.CSV"
Changing the script to point to all these locations provides the same error message.
Any thoughts on how to overcome this? Presently, my only alternative is to use the SQL Server Import/Export tool, but it takes a while to setup every import. Script is faster.
A bulk insert runs from the server. So it can't reach your local disk.
The server uses the account that the "SQL Server" Windows service uses. That account typically does not have any mapped drives.
Try using a full name, like:
\\server\share\test.csv
Possible other solutions:
Ask a DBA to open a share on the server for imports
Ask a DBA to place the CSV file on a disk on the server
Ask the DBA which account is used for the SQL Server service. If it's a domain account, you can give the account read rights on a network share.
I experienced this error, too.
In my case the solution was to change the path in T-SQL from a share to the actual directory: \\server\share$\file -> drive:\folder\file.
The culprit ended up being a problem with VMWare, which caused the server to have trouble authenticating with some network shares.