ACC: Error Opening Linked dBASE Table (141104)

CAUSE

When two or more Microsoft Access databases have tables that link (attach) 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 re-create 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:

Open the .inf file in Notepad.
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

Both computers can now view the linked dBASE table without generating the error message. Without a full path specified on the NDX1 command line, Microsoft Access always looks in the default folder (directory) for the .ndx file specified. The default folder is the folder where the .dbf file resides.

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.

On Computer1, create a folder in the root of drive C and name it Dbase.
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.
Copy the necessary .dbf and .ndx files to the C:\Dbase folder.
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.
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.
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>'

This occurs because Computer1 is looking for the index file using the NDX1 setting created during the link by Computer2. If Computer1 relinks to the dBASE file, it creates a new .INF file and NDX1 setting. Computer2 then receives the error if it tries to view the linked dBASE table.

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.