We have set up Data Source to Oracle on our SSRS 2008 reporting manager as simply:
Data Source: Oracle (from drop down list) Connection string: Data
Source=SERVERNAME;Unicode=True
And it all works fine until something happens - we assumed after windows updates.
This connection doesn't work. The error is:
"Attempt to load Oracle client libraries threw
BadImageFormatException. This problem will occur when running in 64
bit mode with the 32 bit Oracle client components installed."
We do have 32bit Oracle driver on this server. I don't know if there is a 64bit one already.
Then we have created another one to ORacle but is ODBC:
Data Source: ODBC (from drop down list) Connection string:
DSN=SERVERNAME;
After this one is tested for connection (with the button in the properties window) the first one starts working.
And then we continue with the Oracle Data Source as usual and until the next failure. It happened couple of times so far and the solution is just to open the ODBC connection, hit "Test Connection", that works fine. Then go back to Oracle data source and that one works.
It is very unreliable to operate reporting service for the users and also annoying for staff as we don't have a solution.
Any ideas for what we might be looking on that server to have it working 100% of time?
You are running your SSIS package in 64 bit mode but attempting to access a 32 bit driver.
Either (a) switch to 32 bit mode or (b) uninstall your 32 bit driver and install the 64 bit one. You really do not want both 32 and 64 bit on the same server :-)
As to why it is happening infrequently? Hard to tell because there is insufficient information in your question.
If your windows is is 64 bit, and oracle client is 32 bit,
install both clients (32 and 64 bit) in separate folder path with same tnsname file and restart SQL Server Reporting Server service. It get solved for me.
Related
Want to use an Oracle-ODBC connection in Visual Studio 2017/ SSIS as it's much faster than OLE DB during tests.
Problem:
I follow Oracle's steps to the letter.
Install instant client (v18, also tried v12).
Download/ extract ODBC download in same library. Run odbc_install.exe.
See the Driver in 'ODBC Data Sources/ Admin' in Windows 10.
Add new User Data Source. TNS Service names pull up fine. Test
Connection (User/ Pass) -- it works!! The Connection works!!
I tried this with 64 bit in Oracle, their instant client v18.3 or 12.2 both. All works in Window's "Oracle Source Administrator" via test connections.
I tried this with 32 bit downloads as well. All is good.
Now, open Visual Studio. First tried 64 bit (my Windows OS is 64 bit, but Visual Studio Data Tools is only 32 bit). Had a hunch it wouldn't work.
Error message "system architecture and client is not the same" or such. Gotcha.
Tried the 32 bit Oracle ODBC driver (User Source). I keep getting the same message (tried 18_3 and 12_2 versions).
Now .... SQLORA32.dll is in the very file path it named. It's right there! Why can't it be found? The test connection in ODBC Source Admin works! What is going on here?
And I'm unsure if I have to "register" something via the command line, I had to do that once before, maybe it was an unrelated issue.
To boot, when I tried a 3rd party "Devart Oracle ODBC connector" -- it's a simple 5-second install wizard that works flawlessly instantly. Problem is it's a 30-day trial and costs $150 at least. How can I can get an Oracle-created ODBC connector (Oracle being world-renowned for janky-azz products) to actually work?
Devart, and probably Attunity Oracle ODBC: 5 second installs
Oracle's own: Harder to install than breaking into Fort Knox/ learning Mandarin Chinese. Please advise.
I am answering my own question.
Unfortunately some of us ETL/ BI guys need to go so wide on problems that there's no time to figure out every little detail/ glitch of Oracle's ... whatever they're doing now.
But here's a fix. In Visual Studio 2017/ Data Tools/ the SSIS IDE .... if you want an Oracle ODBC connection (Faster than OLE Db for some reason) --- when you're setting it up, instead of selecting a NAMED "user or system data source" that you created in ODBC Source Administrator, simply using the "Builder" option (to the left of Use Connection String) for a connection string. It does the exact same steps as the ODBC Source Admin, but within Visual Studio. I don't know what the difference is here, but some wizardry/// who knows what is different, and the connection somehow, suddenly, for some reason, works.
We have a number of applications written in VB6 (not .NET) that have been running for almost 20 years.
These applications are running on Windows 2007 64bit servers and connecting to Oracle-11 with a 32bit client.
The connection string contains "Provider=OraOLEDB.Oracle"
So far, so good.
The problem is that we need to convert, for reasons that go beyond the scope of this thread) to Oracle-12 64bit.
After having installed the Oracle 12-client (and disinstalled the Oracle-11 client), we get the following error when trying to open the connection:
"Provider cannot be found. It may not be properly installed."
I'm sure we did install the client and am therefore afraid that VB6 cannot connect to Oracle using the 64bit client.
Apparently easy solutions are unfortunately out of the question:
- Convert to .NET or whatsoever and compile under 64 bit
- Keep the 32bit oracle client.
Any idea how to risolve this?
OLE-DB
Good news and bad; because Visual Basic 6.0 is a 32 bit program with no 64 bit compiler, the 32 bit Oracle Data Access Components software must be installed, even if the database itself is running on a 64 bit server in a 64 bit Oracle Database install, specifically you need the 32 bit Oracle Provider for OLE DB rather than the whole client.
The driver can be found here (Download the ODAC XCopy version):
http://www.oracle.com/technetwork/database/windows/downloads/utilsoft-087491.html
The following thread describes your exact problem and instructions on fixing it:
https://hoopercharles.wordpress.com/2012/11/25/connecting-to-an-oracle-database-with-visual-basic-6-0-on-windows-8-64-bit/
ODBC drivers
Another way to connect is to use ODBC drivers instead, there are pros and cons to each method so google to find them.
First you'll need to install the SQORA32 ODBC driver which comes with the 64 bit client or with the ODAC linked above.
Next, you'll need to create an ODBC connection, instructions can be found here:
https://tensix.com/2012/06/setting-up-an-oracle-odbc-driver-and-data-source/
Finally you need to change your connections strings in VB6 to use the newly created ODBC connections. Something along the lines of the following should work nicely (obviously nameOfDatabase is the name given to your odbc connection):
Provider=MSDASQL;Dsn=nameOfDatabase;Uid=usernameHere;Pwd=passwordHere
Be careful when you set up your DSN, make sure you use the 32 bit ODBC connection manager which can be found in the following location:
c:\windows\sysWOW64\odbcad32.exe
The same program can be found in the system32 folder but that's the 64 bit version....not confusing at all!
(If you can't follow the solution of twoleggedhorse, which is way better.)
You can write a small DLL in .NET 32bit, and make it COM visible so it will be usable by your 32 bits application.
I said in my comment that it seems to be possible in .NET to talk with the DB without an installed client.
To make it through the least painful, you can write it ADO-like (ie a class to replace RecordSet, another for Connection, and so on). Then add it as a reference to your projects and perform a search/replace.
Per
http://www.accessmvp.com/djsteele/DSNLessLinks.html
I've attempted to replace DSN-created table defs in Access with a DSN-less connection.
No luck trying the driver from Microsoft:
Microsoft ODBC for Oracle
because of this specific issue:
https://support.microsoft.com/en-us/kb/942976
On Windows 7 64 bit, you have to manage the ODBC driver (DSN) using the 32 bit ODBC Admin panel, if you want to use Access 2013 32 bit.
However, that doesn't solve the issue because I'm trying to go DSN-less in the first place.
I assume that the reason the connection doesn't work is that Windows is "helpfully" choosing the 64-bit version of the driver when I use this as my connection string:
strConnectionString = _
"ODBC;DRIVER={Microsoft ODBC for Oracle};" & _
"Server=" & ServerName & ";" & _
"UID=" & UID & ";" & _
"PWD=" & PWD & ";"
The issue is I can't specify that I want the 32-bit version of the driver, because both versions (32 and 64) have the same name.
Is there a way around this?
Thanks,
Chad.
The location of driver you can check in your Registry. In case of x86 (32 bit) check HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\Microsoft ODBC for Oracle\Driver. Most likely the value should be %WINDIR%\system32\msorcl32.dll
Now, in case you run a x86 application like your MS Access folder %WINDIR%\system32\ is automatically redirected to %WINDIR%\SysWoW64\ (see WoW64), so you (or MS Access) will find file msorcl32.dll in folder c:\Windows\SysWOW64\.
In principle for x64 you would have to check Registry value HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft ODBC for Oracle\Driver, however Microsoft ODBC Driver for Oracle is deprecated and available only for 32 bit! In case you need a 64 bit version you have to download and install ODBC driver from Oracle.
Your 32bit Access should work without any problem using 32 bit ODBC drivers.
There is no confusing issues, since an “in-process” x32 program will only load and use the x32 driver. And an “in-process” x64 bit program will only load and use the x64 driver. They both can have the same name, but they are installed and in different locations on the OS.
And if you read your linked articles, the simple solution is to always launch the correct version of the ODBC manager. And the simplest way to do this is to create the link from inside of access since access will ALWAYS launch the correct ODBC manager.
And at the end of the day, since you using DSN less, then this further means the links you use have zero to do with your question and issue.
So while the drivers might have the same name, the OS and software can ONLY use the same bit size software and thus that what will be used in your case.
The only issue you want to check is while in Access you want to launch on the external data tab from import and link the ODBC manager. At that point you link a single table to oracle using that manger and then access will grab (copy) that connection string. And you note that if no oracle driver is displayed, then you have to install the oracle driver (but likely the oracle driver already exists).
Then AFTER verifying that the link works, then simply hit ctrl-g to jump to the debug window, and display the connection string setup with this command:
? currentdb.TableDefs("table I just linked").Connect
You then see the connection string used, and the name/syntax of the oracle drive will be shown – that’s what you use in your connection string.
I should also point out that when launching the ODBC manager from Access the “default” tab is “File data source” – this will ALWAYS create a DSN less connection in Access. So Access by default will always use and create a DSN-less connection. The File Data Source is ONLY used at create time. Once you created the linked table then you could for example move the database to a different computer and the table link will continue to just work fine due to Access using DSN links by default (so the information is “copied” to the table def connection string for that linked table – the original file data source from that point on that you saved via the ODBC panel is ignored and not used.
Bottom line:
All those links to those articles don’t matter and are NOT your problem or issue. You simply have to create a linked table using the GUI in Access to oracle. If that works, then simply look at the connection string for that linked table as per above and it will show/display the correct driver string you need to use.
Here's the issue and how it was solved:
Legacy system that started probably in Access 97 (.mdb) that is currently in Access 2013 (.accdb) format. (We aren't budgeted to re-platform the system until next year)
There are hundreds of linked ODBC tables to Oracle data sources, only a handful of which are actually used. Only 15 tables were either being used directly or being subsequently linked by other .accdb databases.
The root of the problem was that four of the tables had been created using either a now missing DSN, a missing or out-of-date user id, or a bad password.
Users would see the "ODBC link failed" message during one of their processes and have to go to linked table manager and puzzle through the names of the tables to figure out which ones to re-link. (Usually they'd select all 200 of them).
Then they'd get prompted to update the DSN/UID/PWD.
Of course when doing that, Access 2013 doesn't save that information to the tabledefs... so every time the users would try to run their processes again, they'd see the ODBC failure message again.
The solution was to drop and re-add the four linked tables with the up-to-date DSN.
I also added a button for them on the main form that went through the shortened list of ODBC linked tables (only 15 of them) and ran TableDef(_TABLENAME_).RefreshLink on the table def for them.
Thank you to both Albert and Wernfried for the insights.
(I'm hoping to be part of the team that replatforms the system to exist all in SQL Server and/or Oracle (backend) with the front end in HTML 5 next year, so this was a good stop gap).
If I try to connect via Excel to a database I get the following Error:
test connection failed because of an error in initializing provider excel
I searched for the reason and found that I have to use 32 bit version of Oracle client while the 64 bit version is at the moment installed.
I read that I have to add it in C:\Windows\System32\odbcad32.exe
But as one can see in the
there is no option like ..\oracle11g_32.
How can I solve this problem?
Thanks a lot
I'm trying to make a BDC connection in Sharepoint 2010 to an Oracle Database using an assembly. When unit testing the assembly, it works perfectly, but when using it in the BDC, I get the following exception: 'The provider is not compatible with the version of Oracle client'
The rest of the BDC model works fine; if I return dummy objects instead of actual Oracle results from my assembly, they show up as they should.
Any ideas?
Make sure of the following:
1. You can connect with another oracle client from the same machine.
2. The Running code and the called assembly has the same bit executable (32\64)
For me the latter was the problem and had to reinstall..
I still have no idea why it wouldn't work, but I circumvented the problem by using a WCF service for the BDC connection instead of an assembly.
Suspicions regarding the original cause go towards a 32/64 bit conflict (although compiling everything to 64 bit didn't resolve it) or perhaps a conflict between 64 bit ODP.NET and Win 2k8 ("The 64 bit ODP.NET for Oracle 11 does not work on Win2k8 64 bit.")