ADODB.Connection error ‘800a0e7a’ – Provider cannot be found. It may not be properly installed

System Requirements:

  • Windows NT 4.0
  • Windows 2000
  • Windows XP (x86)
  • Windows Server 2003 (x86)
  • Windows Server 2008 (x86)
  • Windows 7 (x86)
  • Windows Server 2003 (x64)
  • Windows Vista (x64)
  • Windows 7 (x64)
  • Windows Server 2008 (x64)
  • Windows Server 2008 R2 (x64)
  • Windows Server 2012 (x64)

The Problem:

When you attempt to connect to a Microsoft Access database using the ODBC provider Microsoft.Jet.OLEDB.4.0 you receive the error message:

ADODB.Connection error ‘800a0e7a’
Provider cannot be found. It may not be properly installed./path/file.asp, line ##

 

More Information:

For x64 Systems:

The Microsoft.Jet.OLEDB.4.0 is only available as a 32-bit (x86) module. In order to use it via IIS you must change the web site to run in a 32-bit application pool.

Under IIS 7.0, 7.5 or 8.0:

  • Assuming that you will not want to use ASP .net, in the IIS console in the Application Pools section, create a no managed code, integrated application pool. If you do want to maintain access to ASP .net, select the framework version you require.
  • Once created, in its advanced settings set “Enable 32-bit Applications” to true
  • In the Basic Settings… for the web site entry you are experiencing the error on, change the Application Pool to the newly created 32-bit pool.
  • Restart the web site

In most cases where the system is running under an x64 architecture, this should fix the problem.

For x86 and x64 Systems:

We had a server down for an entire day because of this one. It was either an attempt to fix a security database fault, or an update from Microsoft Update delivered in the April 2008 patch cycle, but after the reboot for the patches, none of the JET (Access) databases on the particular server, in any IIS web would operate.

I will simply cut to the fix for you in the beginning, to expedite your likely finding of a resolution to this problem. Something had caused the service provider for the Microsoft.Jet.OLEDB.4.0 provider to become unregistered. To fix the problem issue the following command from a Command Prompt or Run:

regsvr32.exe msjetoledb40.dll

You shouldn’t need to reboot to solve the problem, it didn’t in my case. However, if nothing happens do restart before progressing to the next step.

 

Additional Steps: Step 1

Reregister the components from MDAC, JET and ADO in their entirety. Simply copy the below into a BAT file and run it.

:: ADODB.Connection error '800a0e7a'

:: Provider cannot be found. It may not be properly installed.regsvr32.exe cfgmgr32.dll -s

regsvr32.exe cliconfg.dll -s

regsvr32.exe dasetupr.dll -s

regsvr32.exe dbmsgnet.dll -s

regsvr32.exe dbmsrpcn.dll -s

regsvr32.exe dbnetlib.dll -s

regsvr32.exe dbnmpntw.dll -s

regsvr32.exe expsrv.dll -s

regsvr32.exe msadce.dll -s

regsvr32.exe msadcer.dll -s

regsvr32.exe msadcf.dll -s

regsvr32.exe msadcfr.dll -s

regsvr32.exe msadco.dll -s

regsvr32.exe msadcor.dll -s

regsvr32.exe msadcs.dll -s

regsvr32.exe msadds.dll -s

regsvr32.exe msaddsr.dll -s

regsvr32.exe msader15.dll -s

regsvr32.exe msado15.dll -s

regsvr32.exe msadomd.dll -s

regsvr32.exe msador15.dll -s

regsvr32.exe msADOX.dll -s

regsvr32.exe msadrh15.dll -s

regsvr32.exe mscpxl32.dll -s

regsvr32.exe msdadc.dll -s

regsvr32.exe msdadiag.dll -s

regsvr32.exe msdaenum.dll -s

regsvr32.exe msdaer.dll -s

regsvr32.exe msdaora.dll -s

regsvr32.exe msdaorar.dll -s

regsvr32.exe MSDAOSP.dll -s

regsvr32.exe msdaprsr.dll -s

regsvr32.exe msdaprst.dll -s

regsvr32.exe msdaps.dll -s

regsvr32.exe msdarem.dll -s

regsvr32.exe msdaremr.dll -s

regsvr32.exe msdart.dll -s

regsvr32.exe msdasc.dll -s

regsvr32.exe msdasql.dll -s

regsvr32.exe msdasqlr.dll -s

regsvr32.exe msdatl3.dll -s

regsvr32.exe msdatt.dll -s

regsvr32.exe msdaurl.dll -s

regsvr32.exe msdfmap.dll -s

regsvr32.exe msjro.dll -s

regsvr32.exe msjtes40.dll -s

regsvr32.exe msorc32r.dll -s

regsvr32.exe msorcl32.dll -s

regsvr32.exe msvcirt.dll -s

regsvr32.exe msvcrt.dll -s

regsvr32.exe mswdat10.dll -s

regsvr32.exe mswstr10.dll -s

regsvr32.exe msxactps.dll -s

regsvr32.exe msxml3.dll -s

regsvr32.exe msxml3a.dll -s

regsvr32.exe msxml3r.dll -s

regsvr32.exe mtxdm.dll -s

regsvr32.exe mtxoci.dll -s

regsvr32.exe odbc16gt.dll -s

regsvr32.exe ODBC32.dll -s

regsvr32.exe ODBC32GT.dll -s

regsvr32.exe odbcbcp.dll -s

regsvr32.exe odbcconf.dll -s

regsvr32.exe ODBCCP32.dll -s

regsvr32.exe ODBCCR32.dll -s

regsvr32.exe ODBCCU32.dll -s

regsvr32.exe ODBCINT.dll -s

regsvr32.exe ODBCTRAC.dll -s

regsvr32.exe oledb32.dll -s

regsvr32.exe oledb32a.dll -s

regsvr32.exe oledb32r.dll -s

regsvr32.exe setupapi.dll -s

regsvr32.exe sqloledb.dll -s

regsvr32.exe sqlsrv32.dll -s

regsvr32.exe sqlunirl.dll -s

regsvr32.exe sqlxmlx.dll -s

regsvr32.exe vbajet32.dll -s:: OLEdB

regsvr32.exe %SystemRoot%\System32\msjetoledb40.dll:: Jet

regsvr32.exe %SystemDrive%\Program Files\Common Files\Microsoft Shared\DAOdao360.dll -s

regsvr32.exe %SystemRoot%\System32\expsrv.dll -s

regsvr32.exe %SystemRoot%\System32\msexch40.dll -s

regsvr32.exe %SystemRoot%\System32\msexcl40.dll -s

regsvr32.exe %SystemRoot%\System32\jet500.dll -s

regsvr32.exe %SystemRoot%\System32\msjet35.dll -s

regsvr32.exe %SystemRoot%\System32\msjet40.dll -s

regsvr32.exe %SystemRoot%\System32\msjetol1.dll -s

regsvr32.exe %SystemRoot%\System32\msjint40.dll -s

regsvr32.exe %SystemRoot%\System32\msjter40.dll -s

regsvr32.exe %SystemRoot%\System32\msjtes40.dll -s

regsvr32.exe %SystemRoot%\System32\msltus40.dll -s

regsvr32.exe %SystemRoot%\System32\mspbde40.dll -s

regsvr32.exe %SystemRoot%\System32\msrd2x40.dll -s

regsvr32.exe %SystemRoot%\System32\msrd3x40.dll -s

regsvr32.exe %SystemRoot%\System32\msrepl40.dll -s

regsvr32.exe %SystemRoot%\System32\mstext40.dll -s

regsvr32.exe %SystemRoot%\System32\mswdat10.dll -s

regsvr32.exe %SystemRoot%\System32\mswstr10.dll -s

regsvr32.exe %SystemRoot%\System32\msxbde40.dll -s

regsvr32.exe %SystemRoot%\System32\spmsg.dll -s

regsvr32.exe %SystemRoot%\System32\vbajet32.dll -s

:: ADO
regsvr32.exe %SystemDrive%\Program Files\Common Files\System\ado\msader15.dll -s
regsvr32.exe %SystemDrive%\Program Files\Common Files\System\ado\msado15.dll -s
regsvr32.exe %SystemDrive%\Program Files\Common Files\System\ado\msadomd.dll -s
regsvr32.exe %SystemDrive%\Program Files\Common Files\System\ado\msador15.dll -s
regsvr32.exe %SystemDrive%\Program Files\Common Files\System\ado\msadox.dll -s
regsvr32.exe %SystemDrive%\Program Files\Common Files\System\ado\msadrh15.dll -s
regsvr32.exe %SystemDrive%\Program Files\Common Files\System\ado\msjro.dll -s

Additional Steps: Step 2

Reinstall MDAC 2.8 SP1 (Windows XP SP1 or below only). You will need to perform some registry modifications before you can reinstall MDAC as it is a protected system module.

  1. Open Regedit
  2. Navigate to:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ExceptionComponents
  3. Look through each class ID for the following friendly name values. Delete the Class ID containing the matching friendly names:
    Microsoft MDAC Response Files
    Microsoft MDAC Setup Files
    Microsoft SQL Server ODBC Drivers
    Microsoft SQL Server Net Libs
    Microsoft SQL Server OLEDB Provider
    WebData Setup Exception Package
    Mdac 2.8 Exception Package
  4. Download and reinstall MDAC 2.8 SP1 from Microsoft which should reinstall in full.

Error 0x80004005: “Could not use ‘(unknown)’; file already in use” when using Microsoft Access databases in conjunction with IIS, Dreamweaver and others

System Requirements:

  • An Access database
  • Internet Information Services (IIS) 4.0, 5.0, 5.1, 6.0, 7.0
  • Dreamweaver

The Problem:

This error can arise for a variety of reasons, however the specific one which prompted me to write this was to do with using IIS and Dreamweaver to fiddle with its ‘Application’ management system for connecting to and inserting dynamic information onto web pages.

When you attempt to use the database you receive the following error message in your web browser:

Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Microsoft Access Driver] Could not use ‘(unknown)’; file already in use.
/<file>.asp, line #

This occurs despite giving the IUSER_<system_name> account permissions to access the MDB file.

The Fix:

This could be:

  • A bad/corrupt MDAC install
  • An old MDAC install; ensure you are using 2.8
  • An old version of JET – ensure that you have the latest 2000/XP/2003 service pack or have installed Jet 4.0 SP8 on anything else

However is is more likely that you are running into a permissions error (yes, even though you gave the IUSR_<system_name> permissions on the MDB).

When you are using an Access database, of course the IIS service account IUSR_<system_name> needs to have correct permissions on the .MDB file that you are using. This goes without saying.
If you haven’t got that far, ensure that you have disabled simple file and folder sharing (on XP Pro) and offer up modify permissions or higher (do so with care) on the .mdb, however this will not solve the error!

When you use an Access database, during that fleeting second when the database is being structurally polled, Access will lock the database to prevent concurrent activity from taking place, however it does this in a relatively unsophisticated manner using a file-system flag.

By default Access will attempt to create the file system flag, a .LDB file named in an identical fashion to that of your database next to the .MDB. The problem is that the LDB is being written using the IUSR_<system_name> account which under Windows 2000 will be part of the everyone group, and has more secure default permissions under later version.

What is happening is that your system is either unable to create the LDB because of a permissions conflict, or more likely in the case of you receiving the error listed at the beginning of this article it is creating the LDB file, but is unable to clear the file-system flag.

In other words: Access is locking the database, but in its crudeness is unable to unlock it!

You must ensure that you have set the necessary permissions on the database folder/directory with the permissions on the folder inheriting down to the files contained within it.

 

Now that you have a folder with write/modify (or worse) permissions for the IIS process/guest account, you need to think about security. Never, ever put the database folder beneath the public wwwroot of the site. Always place the database directory at the bottom of a folder hierarchy and always keep your permissions as tight as possible.