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.")
Related
I have been working on an API to run queries on a FoxPro database via PHP (v7.3) using ADODB (v5.20.14). Currently, my working solution uses XAMPP (3.2.2 x86), running on a Windows 2019 server. FoxPro driver (6.01.8629.01).
I'm now trying to get this same setup working using IIS 10, however, I'm running into a strange issue where if I send simultaneous requests to the web server, only the last request will return back data successfully; the issue lies in $db->connect. This is the connect code that I am using:
require_once('adodb/adodb.inc.php');
$db = NewADOConnection("vfp");
$ADODB_FETCH_MODE = ADODB_FETCH_ASSOC;
$db->debug = true;
$db->connect("DSN=Visual FoxPro Database;UID=;SourceDB=<UNC PATH>.DBC;SourceType=DBC;Exclusive=No;BackgroundFetch=Yes;Collate=Machine;Null=Yes;Deleted=Yes;") or die("Failed to connect.");
The error that I get back on all but the last request is:
odbc_connect(): SQL error: [Microsoft][ODBC Visual FoxPro Driver]This file is incompatible with the current version of Visual FoxPro. Run 30UPDATE.PRG to update the file to the current version., SQL state S1000 in SQLConnect
I have found this KB article on the error which seems to suggest that it's an erroneous error; it's misleading.
If you open a database located on a server numerous times from multiple Visual
FoxPro 6.0 executables, then the following error randomly appears:
This file is incompatible with the current version of Visual FoxPro. Run
30UPDATE.PRG to update the file to the current version.
This error may also occur if you are opening a Visual FoxPro 6.0 database using
ADO or the Visual FoxPro ODBC driver.
I don't believe that this is very helpful as it works when executed via XAMPP, just not IIS. IIS application pools are set to use x86 as ADODB and the FoxPro driver require 32 bit.
I'm not sure what is causing this behavior and why the last request works every time, the connection to the dB is established and data is returned successfully.
Unfortunately, this seems to be an issue with version 6.x of the VFP driver which won't be fixed as VFP was made end of life some years ago; extended support for v9 ended in 2015, you can see the lifecycle here.
I can't speak for the difference between IIS and XAMPP but they use different underlying technologies.
Considering the age of VFP, I presume that you're using v6 to support a legacy system? In which case, there's no fix for this issue other than to use a third party xBase driver which supports VFP, there are plenty out there and should work for your existing setup.
You are saying ADODB but erroneously using ODBC driver, which latest version was 6.x. You cannot access newer version of VFP tables with that driver. Use VFPOLEDB driver instead, it works wonderfully well with ADODB (32 bits). Unfortunately I am not using PHP, so I can't give an example with PHP.
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 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.
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.