Microsoft recommends keeping all data tables in one database and
placing the forms, queries, modules and so forth in a separate 
database. With this technique you can distribute updates to your
program by providing a new "local" database, while leaving the 
"remote" data-database undisturbed. Tables in the remote database
are "attached" to the local database, and for the most part you
can use these tables as if they were part of the local database.

The problem with this approach is that Access "hard-codes" the
location of the database containing the attached tables into the
local database at the time that you make the attachment. This
means that the user MUST use the same drive letter and directory
path that you establish when you attach the tables.

This project shows a technique which allows you to attach all the
tables in your database dynamically when the database is first
opened. You prompt the user for the location of the attached
database, and the program automatically runs the appropriate 
TransferDatabase command for you. When you run the application
again, the function notices that the tables are already attached
and simply continues on with the application.

The program works by keeping a local table which has the names of
all of the remote tables which need to be attached to your local
database. When you distribute your application you UNATTACH all of 
the remote tables. (An update query is provided to make this easy.) 
The table keeps track of the LOCATION of the database containing the
remote table, and contains a FLAG which tells us whether or not the 
remote table has been attached.

Each time you run the application you call a custom function from 
the autoexec macro. The autoexec macro runs every time you open 
the database. You provide the function with two pieces of information: 
  1) the name of the table to examine in your "Attached Table" table to
     determine if the attachment has already been performed, and
  2) The "default" location of the remote database.

If the table has already been attached in a previous session, the function
just exits.

If this is the FIRST time you execute the application, and thus the
tables have not been attached, the function first PROMPTS the user
for the location of the remote database (using the default value) and
then automatically attaches the tables by doing a TransferDatabase
action.

If you have any questions, comments, or suggestions please let me
know.

  Jim Ferguson
  5016-4 Hunt Club Rd.
  Wilmington, NC 28403

  CIS ID: 71477,2345

This version includes enhancements by Ken Getz (76137,3650) to use the
Windows File Open common dialog routines to search for the attached
database.
