ACC: Error Opening Linked dBASE Table

• Microsoft Access versions 2.0, 7.0, 97

SYMPTOMS

Moderate: Requires basic macro, coding, and interoperability skills.

When you attempt to open a shared dBASE (.dbf) database, you may receive one of the following error messages:

   Index file not found

   -or-

   Couldn't open file '<File Name>'

CAUSE

When two or more Microsoft Access databases have tables that link (attach) to a dBASE table (.dbf) and its associated index file (.ndx), Microsoft Access creates an information file (.inf) during the linking process. Microsoft Access gives this information file the same name as the .dbf file and stores the name and the location (path) of the index file being used. Any time a new link is made to the dBASE table and its associated index file from another computer, Microsoft Access prompts you to recreate the .inf file. The new .inf file then contains a new path to the index file, which causes the previous link to have an invalid path.

RESOLUTION

Edit the dBASE file's associated .inf file to remove the full path reference. To do so, follow these steps:

1. Open the .inf file in Notepad.

2. On each of the NDX1 command lines, remove the path to the .ndx file, leaving just the .ndx name. When you are finished, the .inf file should have settings similar to the following:

        [dBase III]
        NDX1=CUSTOMER.NDX
        [UIDX1 CUSTOMER]
        NDX1=CUSTOMER.NDX
   

MORE INFORMATION

The .inf file contains two sections: [dBase <ver#>] and [UIDX1 <dbfname>] where <ver#> is the dBASE version being used (III or IV) and <dbfname> is the name of the dBASE table that Microsoft Access is linking to.

Both sections contain a settings line that begins with NDX1= and is followed by the full path to the index file. Any time a new computer links or relinks to the .dbf file, this path changes with each new creation of the .inf file.

Steps to Reproduce Behavior

For illustration, this example uses two computers (Computer1 and Computer2), each running Microsoft Access 7.0 or 97 under Windows 95. You can also reproduce this scenario with Microsoft Access 2.0 running under Windows for Workgroups, Novell NetWare, and so on. Computer1 is considered the local computer.

1. On Computer1, create a folder in the root of drive C and name it Dbase.

2. In Windows Explorer, make the Dbase folder a shared folder with full access rights. Note that Computer1 views the path to this folder as being C:\Dbase.

3. Copy the necessary .dbf and .ndx files to the C:\Dbase folder.

4. Connect to the Dbase shared folder on Computer1 from Computer2. Note that Computer2 has a path to this share that is different from C:\Dbase.

5. From Computer1, start Microsoft Access and link to the dBASE table in the Dbase folder. Be sure to use its associated index file. Microsoft Access creates an .inf file in the Dbase folder. For example, if the dBASE file name is Customer.dbf, Microsoft Access creates a file called Customer.inf. After linking with Computer1, the settings in this file look similar to the following:

         [dBase III]
         NDX1=C:\DBASE\CUSTOMER.NDX
         [UIDX1 CUSTOMER]
         NDX1=C:\DBASE\CUSTOMER.NDX
   

         NOTE: The section [dBase III] appears as [dBase IV] if you use
         dBASE version 4 files.
   

6. From Computer2, start Microsoft Access and link to the dBASE table in the Dbase folder on Computer1. Be sure to use its associated index file. Note that Microsoft Access prompts you if you want to overwrite the existing .inf file in this shared Dbase folder. Click Yes. Note that the settings in this new .inf file look like the following:

         [dBase III]
         NDX1=D:\CUSTOMER.NDX
         [UIDX1 CUSTOMER]
         NDX1=D:\CUSTOMER.NDX
   

   Note how NDX1 is now set to a new drive letter and path. Should Computer1 try to view the linked dBASE table, it generates one of the following error messages:

         Index file not found
   

         -or-
   

         Couldn't open file '<File Name>'
   

The third-party products discussed here are manufactured by vendors independent of Microsoft; we make no warranty, implied or otherwise, regarding these products' performance or reliability.

REFERENCES