locked
'OraOLEDB.Oracle' provider is not registered on the local machine, when working with a console application RRS feed

  • Question

  • User1284890338 posted

    I have a very similar situation as described in below thread:

    The 'OraOLEDB.Oracle' provider is not registered on the local machine, when working with a console application?

    I have website application .Net 4.5, on windows server 2016 and vs2017 with configuration as 'Any CPU'. I have a service layer to connect to oracle database and get the data. It runs very fine and connect to oracle database.

    Now, i have a console application to run a job and once this job completes, i need to update the database. I call service layer from console application to update the database. However this call fails, and gives me 'The 'OraOLEDB.Oracle' provider is not registered on the local machine' error.

    Solution provided in above given post (i.e. compile your console app in x86) does work for me but i don't have this option (as i have dependency on some other things as well).

    Do i have any other option to resolve this issue?

    Friday, January 25, 2019 11:00 PM

Answers

  • User269602965 posted

    Additional note: you can actually install both unmanaged ODAC 32-bit and unmanaged ODAC 64-bit clients, both in the same Oracle Base directory, but each in its own Oracle Home directory.  Then you can pick which driver you would like to use and get the DLL of choice from the installation directory, transfer to the /BIN folder of your application, make a LOCAL reference to it, and compile to the bitness of your chosen driver.  For OLE you must not use ANY CPU but compile to the specific bitness you are using.

    I have mix of 32-bit and 64-bit Oracle ODP.NET console, WPF, and Web applications all running on the same server... both in the older days of the UNMANAGED ODP.NET drivers and in the newer days of using the MANAGED ODP.NET drivers (which are ANY CPU tolerant).

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, January 29, 2019 3:17 AM

All replies

  • User269602965 posted

    Missing from the discussion.

    Did you install 32-bit or 64-bit ODAC with OLEDB driver and Oracle Client? 

    The console app, which is independent of the web application, must be compiled in the same bitness of the OLEDB driver you installed along with the ODAC client on the server.

    Alternatively, you could use the ODP.NET Managed Driver to connect to Oracle from the console application.  In that case, you could put the Oracle Managed Driver DLL in the application BIN folder along with a copy of the tnsnames.ora file, make a local reference to the driver, and then compile as ANY CPU.  I have all my console apps running on the ODP.NET Managed Driver in the same environment as web apps for maintenance jobs like nightly database reports, etc.

    Saturday, January 26, 2019 2:24 AM
  • User1284890338 posted

    i tried both the options, i.e. installed 64 bit ODAC and then later 32 bit ODAC but none of these work.

    Monday, January 28, 2019 5:08 PM
  • User269602965 posted

    To confirm, did you then change from ANY CPU compile to the x84 or x64 specific compile of your application?

    ANY CPU does not work with the unmanaged ODAC drivers.

    If so, share your segment of code showing how you are attempting to create a connection, and then opening the database.

    Monday, January 28, 2019 11:07 PM
  • User269602965 posted

    Additional note: you can actually install both unmanaged ODAC 32-bit and unmanaged ODAC 64-bit clients, both in the same Oracle Base directory, but each in its own Oracle Home directory.  Then you can pick which driver you would like to use and get the DLL of choice from the installation directory, transfer to the /BIN folder of your application, make a LOCAL reference to it, and compile to the bitness of your chosen driver.  For OLE you must not use ANY CPU but compile to the specific bitness you are using.

    I have mix of 32-bit and 64-bit Oracle ODP.NET console, WPF, and Web applications all running on the same server... both in the older days of the UNMANAGED ODP.NET drivers and in the newer days of using the MANAGED ODP.NET drivers (which are ANY CPU tolerant).

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, January 29, 2019 3:17 AM