SQLite Error: The 'DbProviderFactories' section can only appear once per config file (IBM Client Access)

I experienced this problem today.

The machine.config files are located in:

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
• C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
• C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config
• C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config

The corrupted version of machine.config contains:

<system.data>
   <DbProviderFactories>
      <add name="IBM DB2 for i .NET Provider" invariant="IBM.Data.DB2.iSeries" description=".NET Framework Data Provider for IBM i" type="IBM.Data.DB2.iSeries.iDB2Factory, IBM.Data.DB2.iSeries, Version=12.0.0.0, Culture=neutral, PublicKeyToken=9cdb2ebfb1f93a26" />
   </DbProviderFactories>
   <DbProviderFactories/>
</system.data>

Installing the iSeries drivers corrupted the following machine.config files:

| Framework | Platform | Factory Added? | Corrupted Machine.config? |
|-----------|----------|----------------|---------------------------|
|v4.0.30319 |   x64    |     Yes        |   Yes                     |
|v4.0.30319 |   x86    |     Yes        |   Yes                     |
|v2.0.50727 |   x86    |     No         |   No                      |
|v2.0.50727 |   x64    |     No         |   No                      |

It's nice that you only have to worry about IBM corrupting half your machine.config files; and of those only applications that use .NET 4.

Files to fix

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config (ok)
• C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config (ok)
• C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config (corrupt)
• C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config (corrupt)

From an elevated Notepad, open the two files, and remove the extraneous empty <DbProviderFactories/> element, leaving you with:

<system.data>
   <DbProviderFactories>
      <add name="IBM DB2 for i .NET Provider" invariant="IBM.Data.DB2.iSeries" description=".NET Framework Data Provider for IBM i" type="IBM.Data.DB2.iSeries.iDB2Factory, IBM.Data.DB2.iSeries, Version=12.0.0.0, Culture=neutral, PublicKeyToken=9cdb2ebfb1f93a26" />
   </DbProviderFactories>
</system.data>

And you're fixed.

The problem is caused by installing IBM iAccess for Windows -- specifically the .NET Provider for DB2 component. I've seen it firsthand in V7R1, but others have referenced the same issue with V6R1.

IBM is aware of the problem and has a fix in one of the service releases.

From the V7R1 service release documentation:

DESCRIPTION OF PROBLEM FIXED FOR APAR SE45767 :

Under unknown circumstances, corruption to the machine.config XML file is occurring when the .Net data provider is installed (either as part of a Complete or Custom install type). The corruption is isolated to portions of the XML data related to the DbProviderFactories - and generally has been observed to include duplication of some lines of the XML data.

CORRECTION FOR APAR SE45767 :

A preventive fix will be provided which will eliminate the likely cause of the machine.config corruption.

A corrective fix to update already corrupted machine.config files will not be provided. Utilize the documented local fix or circumvention if possible.

CIRCUMVENTION FOR APAR SE45767 :

If the .Net data provider is not needed, this problem may be avoided by performing a custom install and ensuring the .Net Data provider will not be installed. If the .Net provider is required, no circumvention is known. Utilize the local fix to resolve the issue.

As for fixing the problem once it has occurred, you need to fix machine.config (both 32-bit and 64-bit), because it does not conform to the schema defined for system.data. That's easy -- just write a simple .NET app that uses XmlDocument to load machine.config, locate the duplicate DbProviderFactories element, delete it and save the file. Or use a PowerShell script or anything else that can manipulate XML documents.

Here's an IBM APAR discussing this issue in V6R1.