The 'MSDAORA.1' provider is not registered on the local machine

Question

I have an application that connects to a DB, extracts info, creates a excel file, and then drops the file/emails X people the file.

The application was created in Visual Studios using .NET 2.0 Framework (Windows Form App). It was run on a 32 bit server. But it recently was moved to a 64 bit server. It is now returning with the error message " The 'MSDAORA.1' provider is not registered on the local machine."

I believe that MSDAORA is only supported for 32-bit applications and the Application Pool the app runs under in IIS is not enabled for 32-bit applications.

How would I fix this issue, is there something I can change in IIS? Or is it a code change?

Answer 1

Using ORAOLEDB.ORACLE rather than MSDAORA fixed the same issue for me - changing the platform target from 'Any CPU' to 'X86' caused errors within my project in Visual Studio.

See answer here

Answer 2

I figured out the solutions for this. The problem stemmed from running the machine on a 64bit machine. To change that in VS, open up the properties page of the solution and in the build tab change the targeted platform to x86. And that did the trick.

http://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/

Thanks for your help Yuriy.

Answer 3

I had the same issue, but I used another solution because my application is running in IIS.

In the advanced settings of the application pool I changed the value for Enable 32-Bit Applications to true .

Answer 4

I had he same issue but it wasn't 32/64bit. I used the ODAC xcopy installer and forgot to run it in a cmd.exe as administrator . It didn't give any error so I had a hard time figuring this out. The xcopy part worked but the DLL registration via regsvr32 silently failed.

Answer 5

https://docs.microsoft.com/en-us/sql/ado/guide/appendixes/microsoft-ole-db-provider-for-oracle?view=sql-server-ver15

11/08/2018

This feature will be removed in a future version of Windows. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Instead, use Oracle's OLE DB provider.

so probably using ORAOLEDB.ORACLE is the correct solution, but that seems like more effort than just changing the connection string.