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.

Error: Activex componet can not create object: “WScript.Shell” when running WScript application

System Requirements:

  • Windows 95, 98, 98SE, Millennium
  • Windows NT 4.0, 2000, XP, 2003, Vista

The Problem:

When you run a .vbs file with a call to CreateObject(“WScript.Shell”) the script/application terminates with the follow error message:

ActiveX componet can not create object:”WScript.Shell”
Code: 800A01AD

The script then exits

More Information:

Your Windows Scripting Host has a mis-registered control. If you have just Installed Microsoft Internet Explorer <anything>.<anything> chances are the install went wrong. Check the install log in %SystemRoot% and check for failures.

I would recommend reinstalling IE properly to be safe, but chances are the problem will still be there afterward (it was with this particular muse and MSIE 7.0).

The fix is very simple however (assuming that your error is down to Windows Scripting Host and not bad programming; you are on your own on that one).

From cmd, or from a .bat run:

regsvr32 dispex.dll
regsvr32 jscript.dll
regsvr32 scrobj.dll
regsvr32 scrrun.dll
regsvr32 vbscript.dll
regsvr32 wshcon.dll
regsvr32 wshext.dll
regsvr32 wshom.ocx

I recommend that you start with wshom.ocx and test . No reboot is required for shell initiated .vbs files. If the problem is with IIS, you should restart the IIS Administrative and WWW services.

Be sure that you are using WScipt 5.6 (Unless running Vista or XP with IE7). You can download the latest release here:

Microsoft Access asks “Enter Parameter Value” when using the VB/VBA function FormatDateTime()

System Requirements:

  • Microsoft Access

The Problem:

When using an Integer based formatting value when calling the VB/VBA function FormatDateTime() as part of a statement in the Microsoft Access Expressions builder Access fails to process the function call correctly when attempting to preview the form or report. Instead,Access requests you enter a value for the variable ‘formatdatetime’ and ignores the correctly formatted function call as pictured below:

FormatDateTime Error

An example of the the function call which may produce this error would be:
FormatDateTime([database_record],4)

The above function call is designed to take the input date and time string and reformat the output to display only the time in a 24 hour clock format (vbShortTime). The integer value options are predefined as per the table below.

Constant Value Description
vbGeneralDate 0 Display a date in format mm/dd/yy. If the date parameter is Now(), it will also return the time, after the date
vbLongDate 1 Display a date using the long date format: weekday, month day, year
vbShortDate 2 Display a date using the short date format: like the default (mm/dd/yy)
vbLongTime 3 Display a time using the time format: hh:mm:ss PM/AM
vbShortTime 4 Display a time using the 24-hour format: hh:mm

The Fix:

This is an interesting one, because I haven’t conclusively been able to track down why it is doing it in this case. I have increasingly been seeing similar problems with integer based function parameter calls made to and by ADO and VB objects in ASP and VBA on completely unrelated, disparate systems on both workstations and servers and with different Windows/Office combinations on them.

While the error in the case of integer specification of the ADO cursor type .CursorType = i (where i = -1 through 3) is due to a mal-configured call to C:\Program Files\Common Files\System\ado\adojavas.inc, I have not managed to find a similar symptom for the formatdatetime issue outlined above.

There is a very simple fix however, don’t use the integer value, use the full format value string. So, the example of:
FormatDateTime([database_record],4) would instead become FormatDateTime([database_record],”hh:nn”)

The example of:
FormatDateTime([database_record],2) would become FormatDateTime([database_record],”mm/dd/yy”)

This should get you through the Access ‘error’ and force it to realise that you’re calling a VB function and not a private one.