I am having an issue with Oracle connectivity from an SSIS project, and have been Googling around to try to find a solution for over a week, now, and haven't found anything.
I have the following configuration in my dev environment:
O/S: Windows Server 2008 R2 Datacenter, 64-bit
SQL Server Data Tools, 2010
I need to configure an SSIS Data Flow Task to pull data from four different Oracle Data Sources (among others). One is Oracle version 11.1.0.7, two are version 9.2.0.4.0 and one is 9.2.0.8.0.
We use local TNSNAMES and SQLNET.ora files for our configuration.
I have tried this with many different Oracle clients, and basically get the same result, so will highlight one that I did:
Installed the Oracle Client 11gR2 64 bit.
Installed the Oracle Client 11gR2 32 bit (that order is recommended).
Copied my TNSNAMES and SQLNET.ora files into both network/admin configuration folders.
Did a successful TNSPING on each of the 4 databases named above. Successful.
Opened up SQL Server Data Tools and opened a new project
Did a "Create new Connection Manager", picked ADO.NET
Selected "Oracle Client Data Provider", enter the details of the 11g database
Did a "test Connection". Success.
Repeat the procedure for one of the 9.0 databases. When I do the "Test Connection" I get a "Test Connection failed because of an error in initializing provider. ORA-12645: Parameter does not exist".
I get this same result for all three of the 9.x databases.
Oracle "help" says that this error is caused by a missing parameter in the SQLNET.ora file, and that the solution is to add the missing parameter. Trouble is, nowhere does it say what is missing.
I have tried this same procedure with other Oracle client installs other than the two clients - ODTwithODAC1120320_32 bit, ODAC1120320_x64 and get exactly the same result. I can't go to a version 12 client because as I understand it, it won't work with a 9 database. I can't go to a 10 client because that won't work with an 11 database.
I have a feeling that it's very specific to the 64-bit O/S and version of SQL server, but that is our target platform, so need to make it work.
Can anyone help me with this, please?
Related
I'm trying use Microsoft SSMA for Oracle to migrate a database onto Azure SQL, but I can't get it going. I've double checked the server name, server port, Oracle SID, password... everything. No matter the type of entry screen I use, I can't get it to connect to the on-premise Oracle instance.
I'm pretty sure the login information is all correct, and I should have a working connector to Oracle since I connect to it from TOAD on a daily basis. I tried installing Oracle libraries per previous posts but not sure if I did it successfully because the issues still remains.
What are the troubleshooting steps I should take in order to make this work?
Log in screen:
Error 1:
Unable to find specified provider.
Compatible Oracle Data Access Connectivity libraries were not found on the machine. You can install them from Oracle product media or download it from Oracle web site.
Error 2:
Connection to Oracle failed.
ORA-01017: invalid username/password; logon denied
Error 3:
Connection to Oracle failed.
Network Naming: No LDAP server detected or configured
After a few more days of debugging, I was finally able to get SSMA to work. This answer helps to document my solution for personal use, as well as hopefully answer anyone else's question in the future.
After looking at the list of prerequisites to have SSMA running, I saw that I needed to have a correct Oracle client running. After some internal discussion, it was likely that the Oracle client SSMA needed was different than the one my computer already had for TOAD. The .Net provider for the TOAD connectors was probably not useful for SSMA.
We run Oracle 11g but I had to install Oracle 12c because 11g did not support Windows 10 apparently. Not too much of a roadblock here.
I found this guide to install Oracle client 12c pretty helpful. Shoutout to my alma mater.
Unfortunately the installer kept freezer, but using this former post, I was able to bypass it with the windows command:
setup.exe -ignoreprereq -J"-Doracle.install.client.validate.clientSupportedOSCheck=false"
After that, I saw different error messages when trying to connect SSMA. I kept trying different options with my logins until it worked. Provider: OLEDB Provider, Mode: Standard.
After being granted the appropriate permissions, I was finally able to access our internal tables and objects.
It was a pretty annoying question with a lot of rabbit holes along the way, but it was definitely worth it, being able to translate all our Oracle schemas to Azure SQL with a few clicks. Hope this helps!
Make sure to validate all steps mentioned below before going to install Microsoft SQL Server Migration Assistant for Oracle.
Make sure you have already installed SQL Server instance that will host the migrated database. Also keep in mind that you are not installing SQL Server Express edition to host the migrated database.
You must have sysadmin account to install SQL Server Migration Assistant for Oracle.
Make sure to install SSMA for Oracle on the server that will host newly migrated database on SQL Server.
It is recommended to install Oracle client software on your target system where SQL Server Instance is running.
Make sure your windows server has Microsoft Windows Installer 3.1 or a later version. Port 1434 should be open.
For more details, You can reference: How to Install SSMA for Oracle to Migrate Oracle Database to SQL Server.
Here's the Azure Database Migration Guide: Migrate Oracle to Azure SQL Database. As you prepare for migrating to the cloud, verify that your source environment is supported and that you have addressed any prerequisites. This will help to ensure an efficient and successful migration.
Connect to Oracle with Oracle Client Provider.
Azure also has other way can help you migrate Oracle database to Azure SQL database, such as with Azure Data Factory. If you still has the connect error. I think you can try to use it. Please reference this tutorial: Copy data from and to Oracle by using Azure Data Factory.
Hope this helps.
I am trying to connect PowerBI with Oracle-DB with no success.
First: when I open PowerBI and try to connect the Oracle Database on Get Data Icon, I get the following error:
Second: I click ok and try to set the connection mannualy:
But in the end I get the ORA-12145: TNS:could not resolve the connect identifier specified error:
I don't know what's happening since my Oracle version is the most recent one (Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production):
Also, my PowerBI Desktop version is Version: 2.63.3272.40262 64-bit (October 2018)
I've already set up the tsnames.ora and listener.ora files, but nothing helped.
Do you have an idea how to figure that out?
In my case the issue was that I was putting the server name wrong, for example I was just putting my db name like
Server : DB
and the way I fixed was
Server: Server/DB
"Power BI" covers a lot of different components. I presume/guess you mean Power BI Desktop?
Your Oracle Database version is not that relevant. The important piece you are probably missing is the drivers, in this case the Oracle Data Access Client (ODAC) drivers. Here's the page in the manual you should read:
https://learn.microsoft.com/en-us/power-bi/desktop-connect-oracle-database
For legacy reasons, our .NET 4.0 application currently uses both the Oracle OLEDB and ODP.NET providers to connect to an Oracle instance. We have standardized on the 11.2.0.3.0 Oracle client. Both data providers work as expected when one Oracle client is installed.
Issues have been reported on computers that already had the 11.2.0.1.0 client installed. A second client, 11.2.0.3.0, was installed for our application. The installation looks like this:
c:\oracle
\product
\11.2.0
\client_1 <-- (existing) 11.2.0.1.0
\bin <-- OraOLEDB11.dll registered here
\network
\admin <-- TNSNAMES does NOT contain ORACLESVR
\client_2 <-- (new) 11.2.0.3.0
\bin
\network
\admin <-- TNSNAMES contains ORACLESVR
Due to a bug in the 11.2.0.3.0 installer, the OLEDB driver is not registered in the second home, meaning the 11.2.0.1.0 driver remains registered.
This leads to some interesting/odd behavior that I cannot explain:
if the "ODP.NET from 11.2.0.3.0" part of the application is used first, both providers can connect, meaning the "OLEDB from 11.2.0.1.0" is using the tnsnames.ora from the _2 home.
if the "OLEDB from 11.2.0.1.0" part of the application is used first, neither provider will connect, presumably because both are using the tnsnames.ora from the _1 home.
So, once the Oracle home is determined for the application, both clients attempt to use that home, causing complete success or complete failure.
To work around this, we can do things like: register the 11.2.0.3.0 OLEDB provider, add the TNS_ADMIN environment variable, or add ORACLESVR the tnsnames.ora from the _1 home.
However, I want to know WHY this is happening? I cannot find, in the Oracle documentation for each provider, how the tnsnames.ora file is located when two clients are present and TNS_ADMIN is not specified.
How does one provider affect the other?
OLEDB is based on Microsoft COM and each DLL you register has to have a distinct name. Thus you cannot register OraOLEDB11.dll several times from different locations, i.e. OLEDB can be installed only once (per architecture).
In case you try to install several OLEDB on one machine the Oracle Installer creates a mess. It is always a challenge to have several Oracle Clients installed.
These locations are searched for tnsnames.ora, resp. sqlnet.ora:
current path (associated with the running client application)
Environment variable TNS_ADMIN defined for the session
Environment variable TNS_ADMIN defined for the system
Windows Registry Key HKLM\SOFTWARE\ORACLE\KEY_{ORACLE_HOME_NAME}\TNS_ADMIN (for x64) or HKLM\SOFTWARE\Wow6432Node\ORACLE\KEY_{ORACLE_HOME_NAME}\TNS_ADMIN (for x86)
%ORACLE_HOME%\network\admin
I got this list from Oracle Metalink 111942.1 (referring to Oracle 9.x and Windows NT/2000)
I don't know whether it applies for each individual Oracle Provider/Driver you may use. When you trace your application with Process Monitor you can get a different order.
I have a server with an Oracle Database. Using Navicat I can connect to the Database and see the database tables, run queries etc.
I am trying to add ODBC support for Oracle to be used with Crystal Reports.
What I have done so far:
I struggled to install instant client and get it working as shown in some guides. As suggested I downloaded ODAC which bundled on the Oracle ODBC Driver and Instant Client etc.
After installing I had Oracle installed in C:\app\Administrator\product\12.1.0\client_1
I added two Environmental Variable:
%ORACLE_HOME% to go to C:\app\Administrator\product\12.1.0\client_1
%TNS_ADMIN% - to go to C:\app\Administrator\product\12.1.0\client_1\Network\Admin
Once added, I then went to control panel->Administrative Tools->ODBC.
I clicked system DSN and added the connection. The connection was successful.
However, when selecting the ODBC connection via Crystal Reports, the Database is showing the database functions (I assume stored functions as they appear in the functions section for the DB in Navicat). I cannot however, see the actual database tables.
Has anyone else experienced this issue and if so does anyone know how to resolve this. Many thanks for your time
I support some old web applications, VBScript-based ASP for the UI and VB6 COM modules for the business and data access layers. Last weekend, I installed DB2 Connect Enterprise Edition v8 fixpack 14 on several Windows 2000 servers, and one of the web apps errors out on null data when it calls the built in VBScript function FormatNumber. This numeric data is retrieved by a SQL Server query, but the only way the SQL Server column is populated is with the calculated results returned from a DB2 query earlier in a progression through several pages.
When I installed DB2 Connect EE, one of the components loaded was MDAC 2.7. I followed corporate instructions and had the installation save an ODBC System Data Source, which reported a good connection when I tested it after the install.
For what it's worth, the project references in the production VB6 modules pointed to MDAC 2.5. I have tried recompiling and deploying to COM on my test server new versions of the VB6 modules referencing MDAC 2.7. My development environment is Windows XP Pro, with MDAC 2.8 and DB2 Connect EE v9.5 installed. When I deployed the updated VB6 dlls, the CreateObject fails to instantiate the classes with the error message that "The class does not support automation or the requested interface".
I've rolled the DB2 Connect install back and have reinstall v8 of the DB2 runtime client, which was the previous environment. The problem, however, persists.
I don't really get the picture for how things are connected together - where is the SQL Server and where is the DB2.
There are forums on IBM's site for helping out specifically with DB2 Connect EE, wwhich I think is a pretty pricey product (not sure tho).
One way I have seen people do it is configure a SQL server as the data gateway. You can define DB2 as a linked server, and then perform SQL queries through the SQL server in order to get to DB2. Apps need only to be able to connect to SQL Server, not directly to DB2. They get to DB2 indirectly. Depending on the load on the system this may or may not be feasible for you. You can even do joins across data stored separately in DB2 and SQL with this approach.
It's one more option in the toolbox, along with replication, data federation, and so on. I found that it reduces the variability in connectivity.