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.

RFC1766 International Language Identification Downloadable Stores

System Requirements:

  • A Language Code Problem
  • Text/CSV Viewer, Excel 2003, Access 2003

The Problem:

If you have ever been mildly curious in the language ID listing, or ever engaged in a project where language identification was important having to come up with a digital list of the language can be a time consuming business.

This article simply saves you the time, having had me spend the time compile the list for you!

The Fix:

If you need the language list, you can use my files below as a base for your project.

The data source has been taken from Microsoft Windows XP’s registry, so any errors are universally Microsoft’s problem if indeed there are any.

I have made the following three files available:

  • Comma Separated Variable (CSV) Text File
  • Office Excel 2003 Spreadsheet
  • Office Access 2003 Database

The CSV contains:

  1. Hex Code
  2. Language Code
  3. Language Description

The Spreadsheet and MDB Database contain:

  1. Hex Code (Key)
  2. Decimal Code
  3. Octal Code
  4. Language Code
  5. Language Description

 

Download: CSV, Excel 2003 and Access 2003 (22KB)

You may also be interested in my stores for ISO 3166-1 Country Codes.

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.