24-06-2013 13-49-43Oracle Data Provider errors can often be the most useless text you’ll ever read. They never seem to offer any assistance in actually finding out what the problem is.

Take the one I’ve been presented with this morning. The error to the right is one that normally strikes fear into any developer who uses the ODP library for accessing an Oracle database from the .NET framework. Usually it points to a corrupt Oracle Home folder or a misaligned registry entry, but it’s never an easy one to solve.

Having found the problem and identified a solution for todays’ OracleConnection exception I thought I would share it as it’s quite convoluted how this exception fired from a completely unrelated problem.

To prove the problem I’m going to use elements of a software tool I absolutely love, Gibraltar’s Loupe logging software. Loupe is a highly effective “Black Box” for your .NET application/website. It logs everything that occurs, including memory footprint and network usage, plus a whole host of other counters and trace information. At work we use the Loupe Hub setup so that all our data is stored by Gibraltar; we have a desktop app which hooks into this data so we can analyse problems and perform health checks on our versions.

Anyway, back to the issue. After looking at the obvious problems such as corrupt DLLs, misaligned version numbers and out-of-date compilation setups I ventured a bit deeper into the stack-trace. Soon I was left with a pointer to an internal method in the ODP library for reading registry entries, but venture one level deeper and you find that the “registry” method error was due to another exception – “Configuration system failed to initialize”. One level further down (lord, this is going deeper and deeper into the rabbit hole) and we find our why the config system didn’t start up, with the error “Unrecognized configuration section.”

Taking a look at the app.config file (and this is where I’ll use the Gibraltar libraries for some help) there is an upper config section which defines some of the areas further down the file. (The ‘…’ represent areas I’ve snipped for readability)

  <configSections>
    ...
    <sectionGroup name="gibraltar">
      <section name="listener" type="Gibraltar.Agent.ListenerElement, ...>
      <section name="packager" type="Gibraltar.Agent.PackagerElement, ...>
      <section name="publisher" type="Gibraltar.Agent.PublisherElement, ...>
      <section name="sessionFile" type="Gibraltar.Agent.SessionFileElement, ...>
      <section name="viewer" type="Gibraltar.Agent.ViewerElement, ...>
      <section name="email" type="Gibraltar.Agent.EmailElement, ...>
      <section name="server" type="Gibraltar.Agent.ServerElement, ...>
      <section name="properties" type="System.Configuration.NameValueSection ...>
    </sectionGroup>
  </configSections>

Further down the app.config file we use some of the sections we’ve declared…

  <gibraltar>
    <listener autoTraceRegistration="true" ...>
    <packager ...>
    <viewer enabled="true"/>
    <server autoSendSessions="True" ...>
    <autoSendConsent enabled="True" ...>
  </gibraltar>

The problem here is that we’re using a section called “autoSendConsent” but it hasn’t been declared in the “configSections” above. Once we’ve added in that declaration it builds without error.

So, next time you get an OracleConnection exception just investigate the InnerException stack a little closer to see what’s really hiding under that great big exception rock.

I’d be interested in anyone’s thoughts on how to better capture errors of this kind prior to a third party library erroring because of it.

Leave a Reply