Oracle Data Access Components – Development Installation Tips

aka ODAC

start here for latest downloads

Oracle Provider for OLE DB

  • I initially found a free generic database object browser tool called Oracle Maestro
    • i actually wound up landing on a much better tool, linked below, but getting Maestro to work walked me through some troubleshooting which would come up for anything requiring OLEDB connectivity
    • Maestro happened to be 32bit only and as usual, the bitness of our runtime is a fun factor…
  • the need for an OLEDB connection string prompted my handy trick of creating a “test.udl” file and then double clicking it to get into a helpful OLD DB Config Wizard UI… once you’ve configured a connection, just notepad that UDL file to copy/paste the connection string, nice!
  • i didn’t have any Oracle providers loaded on my naked win10 instance so i hit the download site above and initially loaded the 64-bit ODAC 12.2c Release 1 ( for Windows x64
  • back to test.udl… now the Oracle provider was listed but immediately upon hitting “next” i got “Provider is no longer available. Ensure that the provider is installed properly.“…
    • using SysInternals ProcMon i saw it seemed to be failing to find oci.dll … started smelling like a binaries path issue… eventually i flip flopped the order of $\oraclehome64\ & $\oraclehome64\bin in my system path and that went away… perhaps also simply because of a reboot
  • i had a connection string now…
  • however, firing up Oracle Maestro, the Oracle Provider was not listed… that’s when i remembered the deal with 32bit and 64bit OLEDB stacks…
  • now loaded “32-bit ODAC 12.2c Release 1 and Oracle Developer Tools for Visual Studio (”
  • and back to test.udl, here’s where i use another trick… launching c:\windows\SysWow64\cmd.exe and then start test.udl from there makes sure i’m launching the 32bit OLEDB config UI which happens to be via a C:\Windows\SysWOW64\rundll32.exe command line vs C:\Windows\System32\rundll32.exe
  • here is an example “TNS-less” DataSource for OLE DB based connections: (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = = 1521)) ) (CONNECT_DATA = (SID = XYZ) ) )

.Net Core Projects and “ODP.NET Managed Driver” aka ManagedDataAccess

  • Just reference through Nuget however it is not .Net Core Runtime compatible yet (supposedly .Net Core 2.0 savvy version coming end of 2017)…
  • Must run on top of traditional .Net Framework until Oracle releases their .Net Core 2.0 compatible update
  • Under VS2017 the ASP.Net Core MVC project template is friendly to this mix (see next screenshot below)
    • which also gives us the necessary clue to spin up other less flexible Core project templates and manually edit the csproj to net461

nPoco requiring DbProviderFactory vs direct instantiation UNDER .Net Core

  • typical error message: System.ArgumentException: ‘Unable to find the requested .Net Framework Data Provider. It may not be installed.’
  • the gist is the current Core incompatible ODP.Net is expecting to configure our project’s app.config or web.config …
  • yet as we know, Core has shifted to appsettings.json, no .config file present… which leads me to next heading…
  • yet, in this case, there’s simply a 3rd parameter where we can pass the factory like so:
    new NPoco.Database(ConnectionString, NPoco.DatabaseType.OracleManaged, Oracle.ManagedDataAccess.Client.OracleClientFactory.Instance)

Tip – Generally fixing .Net Framework based Nuget lib’s configuration under .Net Core projects

  1. spin up a quick traditional framework console app
  2. nuget reference the culprit Nuget lib as usual (“Oracle.ManagedDataAccess” in this case)
  3. copy the pertinent sections in the resulting app.config to your C:\Windows\Microsoft.Net\Framework(64)\v4.0.30319\Config\machine.config
    • this stack-o clued me in to remember there is both a Framework and Framework64 folder…
    • i’ve noticed, in my environment anyway, an ASP.Net MVC Core site launches under a 32bit process requiring the settings to be present in \Framework
    • while a .Net Core Console app will launch a 64bit process requiring the \Framework64 settings

machine.config entries i wound up editing in as of current version

    <section name="oracle.manageddataaccess.client"
      type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=, Culture=neutral, PublicKeyToken=89b483f429c47342"/>


      <remove invariant="Oracle.ManagedDataAccess.Client"/>
      <add name="ODP.NET, Managed Driver" invariant="Oracle.ManagedDataAccess.Client" description="Oracle Data Provider for .NET, Managed Driver"
          type="Oracle.ManagedDataAccess.Client.OracleClientFactory, Oracle.ManagedDataAccess, Version=, Culture=neutral, PublicKeyToken=89b483f429c47342"/>


snapshot of the nuget install

snapshot of the DbProviderFactory error

3rd Party Tools

Oracle Forms 11g Development Installation Tips

Yeah I actually said Oracle Forms, that product from the 90’s… as one might guess, i happen to be on a legacy conversion project at work…
There’s some rough edges getting these old bits to install and run that i wanted to capture…


  • my project is tied to the Oracle Forms v11g stack… the latest 11.x version at this time appears to be
  • we’re using the web servlet stuff which runs our forms as java applets… it’s actually a pretty slick rich client arrangement for the bygone era it heralds from
  • the primary breakthrough i made was getting it all installed once and then doing “xcopy” deploy of the main “Oracle Home” folder (c:\oracle\middleware) to my other team members’ machines… plus the appropriate registry branch (e.g. HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OH1949191890)

Java dependency

  • JDK required – JRE’s not enough
  • JDK 1.6.0u35 – through painful trial and error i’ve settled on this fairly dated release… i’ve seen various components in this whole stack run on more recent JDK’s but subsequent obscure runtime errors beat me into submission

both 32 & 64bit required

  • we are running on Win10 x64 naturally preferring to install 64bit executables…
  • thereby running the 64bit Forms Builder installation which requires 64bit JDK…
  • however the servlet web site generates 32bit java <code> tag references (i’m kinda thinking IE was 32bit only at the time) so we also need the 32bit JDK installed

Java Applet troubleshooting tips:

  • be aware that Control Panel > Java will most likely only show you the 64 bit control panel…
  • you’ll need to specifically launch the 32bit panel via C:\Program Files (x86)\Java\jdk1.6.0_35\jre\bin\javacpl.exe
  • from there you’ll want to enable the Advanced > Java Console > Show Console, to get some visibility on any exceptions firing
  • and very crucial tip here… Advanced > Default Java for browsers > Microsoft Internet Explorer is always greyed out but you can select that node and hit space bar to select it (nuts)
    • its also probably helpful to go back to the 64bit javacpl and uncheck it there

Browser dependency

  • IE (v11 works) is the only browser that will properly launch the 32bit java applet for us on Windows 10 x64 (not Chrome, not Firefox, not Edge)
  • IE11 can actually run in 64bit or 32bit mode depending on what each page’s elements require and due to the 32bit java tags mentioned above, it spawns into a 32bit IExplore.exe process

Main Installation Steps

  1. stop your virus checker’s active file scan – we’re on McAfee enterprise and everybody is pretty spooked that it interferes with these ancient installs and i had enough problems to go ahead and rule it out
  2. WebLogic Server v1.0.3.6 hard dependency
    • i loosely understand weblogic as the web server backend, “servlets”, which deliver the pages and java applets
    • as mentioned, we’re targeting the 11g/11.x stack which drives this version requirement… seriously, trust me, save yourself the trouble, any other version is not going to work with the 11.x Oracle Forms stack which comes next
    • see download links at the bottom of this page
    • CRUCIAL – make sure to get the “Generic” jar – specifically wls1036_generic.jar
    • CRUCIAL – launch wls1036_generic.jar specifically via the golden JDK above under ELEVATED aka Admin command line like so
      • C:\Program Files\Java\jdk1.6.0_35\bin -jar wls1036_generic.jar
    • DO NOT just double click the .jar to launch, that will typically launch via JRE WHICH WILL ACTUALLY INSTALL WITHOUT ERROR AND THEN BITE YOU when it comes to the Oracle Forms piece… i know, nuts!
    • we went with the default c:\oracle “home” path… which wound up creating a single c:\oracle\middleware folder
  3. Oracle Forms 11.x (v11.1.2.0 is current latest)
    • the x64 zips worked for us…
    • download & extract those zips and fire up the Disk1\setup.exe ELEVATED
    • the prompts are pretty straightforward…
      • and one big important choice is to choose “Install Software – Do Not Configure”… we’ll do the configure step next
      • we stuck with the default “Oracle_FRHome1” path
      • skip security updates (that ship has long since sailed 😉
    • once the install finishes then fire up c:\oracle\middleware\Oracle_FRHome1\bin\config.bat ELEVATED
      • select “configure for development” vs deployment
      • provide the previous weblogic and oracle home paths…
      • we just went with FormInstance1 for the instance path
      • “for development only”, didn’t select the reports bits
      • auto port configuration = yes
  4. Lastly were specific environmental configs, YMMV
    • copy our default.env file to c:\oracle\middleware\user_projects\domains\FORMDomain\config\fmwconfig\servers\AdminServer\applications\formsapp_11.1.2\config
    • copy our formsweb.cfg => c:\oracle\middleware\user_projects\domains\FORMDomain\config\fmwconfig\servers\AdminServer\applications\formsapp_11.1.2\config
    • copy our tnsnames.ora and sqlnet.ora => c:\oracle\middleware\FORMInstance\config
    • copy jacob.jar => c:\oracle\middleware\Oracle_FRHome1\forms\java
    • copy jacob.dll => c:\oracle\middleware\Oracle_FRHome1\forms\webutil (NOT down to either \win32|\win64)
    • CRUCIAL – update registry HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OH1949191890\FORMS_PATH to include your forms “.fmb, .mmb, etc” file paths… we had separate folders for images, forms, libs & menus files to be included there
      • this “KEY_OH1949191890” path is probably different for each installation