I am having DB server on another machine and having asp.net application installed on local machine.
I want to connect remote DB and execute my scripts, since my local machine doesn't have oracle installed
I have go-ogled and tried few links it tells me editing transnames.ora file adding one new entry
But this will not work since my local machine doesnt contain sqlplus
So I would like to now what are the tools I will need to download on local application server to run my scripts.
You need to install oracle driver to communicate with remote server.
There are multiply options:
This 2 will have tnsnames.ora file that you we told about:
Full oracle client
Oracle instant client (small in size)
Tool specific:
oracle jdbc driver for java
cx_oracle for python
something else for other tool
OS specific:
on windows you can setup an ODBC driver to connect to ORACLE
Thanks abhi, filename is corrected.
After installing a client, you need to know where is your database server.
In simple situation you need host, port and sid.
entries in tnsnames.ora look like this:
connectionName =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = yourHost)
(Port = yourPort)
)
)
(CONNECT_DATA =
(SID = yourSID)
)
)
You fill in all information and save the file.
after that you can check connection ( I don't know, if tnsping is shipped with instant client)
>tnsping connectionName
OK (description of a connection)
Useful tip: you can just go to remote server (or some other PC that have db access already configured) and tnsping some connection (you probably already have a standard name for it).
than just grap the output in brackets and put it into your tnsnames.ora.
your connection string:
username/password#connectionname
btw, instead of conenctionname you could put the whole connection descriptions (from tnsnames.ora)
username/password#(description=...)
Now you can use the Oracle Managed Driver which does not require the installation of the Oracle Client on the machine. This is extremely helpful as Oracle Client installations are painful. It requires nothing more than putting the driver in your bin directory and providing an appropriate connection string and provider name.
To install the managed driver via NuGet run...
Install-Package odp.net.managed
You may need to change the provider name (I believe it's Oracle.ManagedDataAccess off the top of my head).
Example connection string...(replace MyHost, MyPort (usually 1521), MyOracleSid, myUsername, and myPassword with appropriate info).
SERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=MyHost)(PORT=MyPort))(CONNECT_DATA=(SERVICE_NAME=MyOracleSID)));
uid=myUsername;pwd=myPassword;
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'm trying to access a third party Oracle database from SQL Server Reporting Services. I had it working on previous versions of SQL Server and Oracle ODAC, but it's been several years. I'm now being forced into an upgrade, and when I try to create the data source in SSRS, I get the following error:
Network Transport: SSL failure in parsing wallet location
I created an ODBC connection and am able to successfully test the connection, so I know all of the settings in tnsnames.ora and sqlnet.ora are correct. I know SSRS is looking at the correct files because I can get a different error by changing the connect identifier to something made up. The wallet is in a sub-directory of the tnsnames file. I have tried placing the wallet location in both files, but no combination seems to work.
tnsnames.ora
<Connect Identifier> =
(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCPS)(HOST = <host>)(PORT = <port>)))
(CONNECT_DATA = (SID = <SID>)(SERVER = DEDICATED))
(SECURITY = (MY_WALLET_DIRECTORY = D:\Oracle\wallet))
)
sqlnet.ora
WALLET_LOCATION= (SOURCE=
(METHOD=file)
(METHOD_DATA=(DIRECTORY=D:\Oracle\wallet)))
Current configuration
Windows Server 2016
Microsoft SQL Server 2016
64-bit ODAC 12.2c
The take away to solving this problem is each time you change the SQLORA.NET file you have to restart the SRSS Windows Service.
I'm looking for a source to explain how to use connection-strings, as a client from Linux. I am working with tcl in Linux environment and get a connection-string that supposed to connect me to a Microsoft SQL server.
Do you know of a good source that shoes how to connect to a server with a connection string, and how to connect from Linux?
All the sources I found online talk about creating server strings, and don't address Linux usage at all.
Your question per se has no sense: "connection strings" is the concept which is not inherent to programming languages or database servers. Connection strings pertain to database connection libraries and usually they even differ between different database drivers used by those libraries.
Now back to the point. Personally, I'm using tclodbc with the FreeTDS driver. How to build connection strings for the FreeTDS ODBC driver, is explained here.
I do not use connection strings directly; instead I use "ODBC sources" which are configured system-wide, in the /etc/odbc.ini file (managed by the unixodbc as packaged in Debian). Basically, that file contains entries like this:
[SERVER1]
Description = MS SQL Server on server1.domain.local
Driver = /usr/lib/odbc/libtdsodbc.so
Servername = SERVER1
and the /etc/freetds/freetds.conf file contains matching entries like this:
[SERVER1]
host = server1.domain.local
port = 1433
tds version = 7.0
client charset = UTF-8
Now, in my Tcl code I have something like this:
set source SERVER1
database connect dbconn $source $user $password
...
I made a program that accesses a firebird DB in network environment.
I access the DB via Network in two different points of the network normally.
But if I open the two programs simultaneously this exception is thrown on the second program, which tries to connect to DB:
"Your user name and password are not definied"
How to access the firebird DB with two connections simultaneously?
This could be caused by using the embedded versionof firebird, which only allows 1 connection. Look at the filename you installed.
If that is the problem then uninstall that and install the clasic or superserver version instead
MAke sure that the Firebird database is hosted on a computer that is running the Firebird server.
ie Install Firebird Server on the computer that has the database.
Then from your client PCs where your app is installed make sure that you are accessing the database by connecting to the Firebird server. This means that whichever component your Delphi app is using to connect to the database needs to have the 'server' property set to the hostname of the database server machine.
Once this is done your apps will be making requests to the Firebird database server which knows how to handle the connections and process the SQL requests and return results.
Most db connection components should allow you to precede the database path with an ip address or hostname like this for example
MyConnection.Database := '127.0.0.1:C:\Databases\testdb.fdb';
Obviously make sure both your programs point to the same ip address or hostname and make sure the login credentials they use are defined on that firebird server.
All firebird server installations (except embedded) can handle multiple connections by default (even using the same user), you shouldn't have to worry about that. Just make sure the client programs are using inputs (ie. db network path and firebird server login credentials) that apply on the server they are trying to connect to. You could just use SYSDBA until you get the connection under control, then start thinking about creating a unique login for your client apps to use.
In the TIBDatabase component, you have to fill the Params property with:
user_name=sysdba
password=masterkey
The Firebird installation in every computer in the LAN has to be set to this default parameters. The computer with problem must have a different access credential.
You have to uninstall Firebird and them reinstall the latest version using the service and super server options, and mark the "use gdi32.dll for retro..."
Tell me if that worked out for you.
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.