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.
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.
All.
I have used a DLL approach explained on How to securely store Connection String details in VBA
This code is running very well on windows 10 64 bit and MS Office 64 bit. But same copy of the files i am not able to use on Wndows 8.1 Pro and MS Office 64 bit.
DLL generated is converted to host machnines environment by using
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\regasm c:\windows\syswow64\OraConnection.dll /tlb /codebase
But still same error i am facing. About environment variables care has been taken.
My Connection string is
"Provider=OraOLEDB.Oracle; Data Source = ; User ID =; Password=";
In the Succesfull machine i was using Release 12.2.0.1.0 for ODAC 12.2c Release 1 as oracle client.
But saw a latest version of the oracle client as 64-bit ODAC 12.2c Release 1 (12.2.0.1.0) for Windows x64 which was released on 1st June 2017.
Installed the same. And my error was resolved. When i observed system environment variables i saw few things added into it.
E:\app\client\Admin\product\12.2.0\client_1;E:\app\client\Admin\product\12.2.0\client_1\bin;C:\Users\Admin\Oracle\;
I dont know actually what they did. But error was resolved.
Can anybody throw highlight on this?
I'm not sure what the DLL buys you beyond simple obfuscation. All you're doing is making it a bit harder to get to but not actually protecting the privacy of it in any meaningful sense. My normal advice for management of connection strings is to simply don't save user/password. Instead, require the users to input the username/password at runtime and ensure that you have Persist Security Info=false in your OLEDB connection. That way, once it's opened, the full connection string is now inaccessible and there's no reference to a password. That's much more secure than sticking it in a variable in a DLL and crossing your fingers nobody knows how to read a memory dump or attach a debugger.
That said, that's not germane to your question, not able to the use the provider. First thing I'd do is to rule out whether the DLL is causing a problem that you didn't expect by removing it and using the provider directly. If it likewise fails, then you know the DLL has nothing to do with it and you need to work out with Oracle's provider documentation to get to the bottom of the issue.
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.
We have a SQL Server production box that has a 32-bit Oracle 11g driver installed. Our current test SQL Server which has the same driver installed has been replaced by a new server that has the 64-bit 12c driver. When we test a SSIS 2012 package that pulls from Oracle and loads SQL, we will run on the new Test SQL Server using the 64-bit DTEXEC.exe utility to run the package.
Q1: Is it by virtue of using the 64 bit DTEXEC utility that the package will automatically seek out the 64 bit version of the driver?
I assume that in the connection string below, Provider=MSDAORA.1 refers to the MS OLE Provider for Oracle, so, I assume that I am not using the Oracle driver. I am not using a DSN.
Q2: Is it looking up the value of the "Data Source" property of the connectionstring, MyOracleResource.MyCompany.COM, and finding the corresponding entry in my tnsname.ora file in one of these folders based on the DTEXEC version that I use to run the package?
C:\Oracle\product\11203_32bit\CLIENT_1\NETWORK\ADMIN
C:\Oracle\product\11203_64bit\CLIENT_1\NETWORK\ADMIN
If so, I am surprised that the MS driver would be dependent on the tnsnames file that is created as a result of installing the Oracle client.
In the Project properties, under Property Pages->Config Properties->Debugging, there is a property, "Run64BitRunTime."
Q3: Am I correct to presume that when running within the IDE that this is the equivalent of selecting either a 32 or 64 bit versiobn of the DTEXE utility to run the package from the cmd line?
When I look at the properties on my Oracle connection object, I see an "ID" property with a value of {0cbfe196-1a88-4b62-8522-b34dbb37ba71}.
Q4: Is this GUID used to identify a particular driver version of the driver and therefore something that could cause of problem when testing in an environment that does not match Production?
<Configuration ConfiguredType="Property" Path="\Package.Connections[MyOracleDb].Properties[ConnectionString]" ValueType="String">
<ConfiguredValue>Data Source=MyOracleResource.MyCompany.COM;User ID=MyUser;Password=MyPassword;Provider=MSDAORA.1;Persist Security Info=True;</ConfiguredValue>
</Configuration>
Q1 - Yes - when you execute a package under the 64 bit version of DTEXEC, it will user the 64 bit drivers. You can test this locally by only installing one or the other and try to run the package. Running under the wrong version will cause the package to fail because it cannot find the drivers.
Q2 - how the server gets resolved depends on how your organization has configured your environment. For example, where I work, there is an environment variable pushed onto each machine which points to network directories where the TNSNAMES files are stored. You must consult your Oracle guru to understand how this works in your environment.
Q3 - The Run64BitRunTime property will cause the SSIS designer to use different versions of DtsDebugHost.exe. Working in a similar way to DTEXEC, it will either run the 32 or 64 bit version depending on how that is set. This is also why that property has no affect once the package is running in production - because you are using a different program to run the package entirely.
Q4 - the id property is assigned and used internally by SSIS. If you click around, you will see that every component has an id. So this has nothing to do with any external elements.
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.")