Using Multiple Databases To Hold Your Application
=================================================

A Microsoft Access technique that is quickly becoming popular is to put
your forms, reports, queries, macros, and modules in one .MDB file and your
data tables in a separate .MDB.


           +------------+        +------------+
           |   forms    |        |            |
           |  reports   |  ----> |  attached  |
           |  queries   |        |   tables   |
           |   macros   |  ----> |            |
           |  modules   |        |            |
           +------------+        +------------+
              Code .MDB             Data .MDB


Separating your data from the rest of your application has several
advantages:

1.  Because your data and application are in separate files, you can easily
    upgrade your application's forms, reports, queries, macros, and modules
    without affecting your data.

2.  Similarly, if you have data that is swapped out occasionally, you can
    easily change the data without affecting the rest of the application.  
    For example, if you like to keep one month's data on-line at a time, you
    can easily swap out the data file at the end of the month and replace it
    with an empty one.  This would also make backing up a very simple
    procedure.

3.  You can build a system where there is one central MDB containing data
    and several individual MDBs containing code and custom queries.  The data
    MDB can be on the server and the code MDBs on local workstations, so
    loading forms and reports is faster and uses less network traffic.

There are also disadvantages to this technique (which will be discussed
more fully below):

1.  Because you are using attached tables, your application will be
    sensitive to changes in drive mappings and in the location of your MDBs.

2.  You cannot create relationships with attached tables.  All other issues
    regarding attached tables apply as well.

3.  You need to explicitly code for the attached tables if you are using
    Access Basic.


Considerations in Using Separate Code and Data MDBs
===================================================

Do Not Change the Location of Attached MDBs Once They Are Attached

Access stores the links to attached MDBs as normal DOS paths.  Thus, if you
change the mapping of the drive to your attached MDB or change the location
of the attached MDB, your application will not be able to find the attached
MDB.  If you want to change the location of a database you need to delete
the attachment and reattach at the new location.

The Microsoft Access Distribution Kit documentation suggests that you
inform your users in your documentation not to move the database to a
different directory or change the drive mapping.


All Issues of Using Attached Tables Apply

Attached tables for the most part are just like regular tables in Access.
However, there are a few key differences that must be considered when
writing applications that work with attached tables:

1.  Attached tables cannot have their structure modified, however, there
    are field properties that are modifiable: Format, DecimalPlaces, Caption,
    DefaultValue, ValidationRule, and ValidationText.  After you have attached
    to a table, you should set these properties if you need them.

	Remember: The above field properties are not carried over from the remote
    database when you attach a table.  Validation rules must be recreated, if
    you had them.

2.  You cannot create relationships with attached tables.  This means that
    Access will not automatically draw join lines between attached tables when
    you build queries.  This also means that you cannot set referential
    integrity checking in the local database with attached tables.  You can,
    however, set referential integrity checking between tables in the remote
    database and Access will maintain it for you, even when the tables are
    attached.


Access Basic:  You Must Explicitly Code For Your External Databases

In a single MDB system, the common approach to opening a database in Access
Basic is to use the CurrentDB() function:

	Set db = CurrentDB()

If your code and data are separate, to open a data table with OpenTable,
you must explicitly open it with the OpenDatabase() function:

	Set db = OpenDatabase("c:\access\nwind.mdb")

Then you will be able to successfully open the desired table with the
OpenTable method:

	Set tb = db.OpenTable("customers")

You cannot open an attached table with OpenTable.  You must use the above
method to open the external database and then open the table.  However, you
can use CreateDynaset or CreateSnapshot on attached tables.

Note that OpenDatabase requires the name of the attached database, which
means that your application will need to maintain the name and location of
the attached database.

User Tip: Open the database once and keep it in a global variable, since
OpenDatabase() takes longer to execute than CurrentDB().


Common Attached Tables Coding Questions
=======================================

How do I attach a table from a macro or module?

The following Access Basic subroutine shows how to attach a table:

   Sub AttachTable (dbname, tbname, tbtype)
       DoCmd TransferDatabase A_ATTACH, tbtype, dbname, , tbname, tbname
   End Sub

The TransferDatabase macro action allows you to import, export, or attach
to tables in other databases.  Look up "TransferDatabase" in on-line help
for specifics on its arguments.

In the above example, "dbname" is the full name of the database to attach
to, "tbname" is the name of the table, and "tbtype" is the type of database
to attach to.  Possible database types are displayed in the Data Source
dialog box when you choose the "Attach Table..." menu item to attach a
table.

For example, if you wish to attach to the Customers table in the NWIND.MDB
sample database, you would enter:

   AttachTable "NWIND.MDB", "Customers", "Microsoft Access"

Important: When you automatically attach to a table, you are making an
assumption about the types of database support that has been installed on
the user's machine.

Note that in the AttachTable function above, the last two arguments passed
to the TransferDatabase action are both "tbname."  The first of the two
arguments is the table name in the remote database.  The second argument is
the name you want the attached table to be in the local database, in case
you want the name in the local database to be different than the remote
name.


How do I attach a SQL Server table?

When attaching to SQL Server, the name of the database will actually be a
connect string, comprised of data source and user information.

The following items should be included in the connect string:
 
  Data Source Name (DSN)     name of SQL Server machine
  Database Name (Database)   name of SQL Server database
  WorkStation ID (WSID)      name of workstation making the connection
                             (optional)
  User ID (UID)              login id
                             (optional, will prompt for if missing)
  Password (PWD)             user password
                             (optional, will prompt for if missing)

Here is a sample connect string:
 
  ODBC;DSN=ServerX;Database=Pubs;WSID=wrkstn1;USID=JohnDoe;PWD=MARCH

Note that passwords are case-sensitive.

Here is a string used in the above AttachTable() subroutine:

  AttachTable "ODBC;DSN=Svr;Database=Pubs","titles","<sql database>"
 
Notice that the data source is "<sql database>".


How do I detach a table from a macro or module?

The following Access Basic subroutine shows how to detach a table:

Sub DetachTable (tbname)
    DoCmd SetWarnings False
    DoCmd SelectObject A_TABLE, tbname, True
    DoCmd DoMenuItem 1, 1, 4
    DoCmd SetWarnings True
End Sub

"tbname" is the name of the attached table to detach.

For example, to detach a table called "Customers", you would call

   DetachTable "Customers"

Note that in the example shown, SetWarnings is turned off before detaching
the table.  Without this, Access will ask whether you wish to delete the
table.


Are Separate Code and Data MDBs Slower Than Single MDBs?
========================================================

Users have generated much discussion on this topic on CompuServe.  While it
seems logical that there will some slow down for using attached databases,
some users have actually claimed that by using separate code and data
files, they have sped up their application.  

Until formal benchmarks present conclusive results, it can be said, based
on user feedback, that there is little or no penalty for using separate
code and data databases.


Microsoft Knowledge Base References
===================================

Q92644		INF: Differences Between Native and Attached Tables

Q88658		INF: Using TransferDatabase Macro to Attach to SQL Server Data

Q93297		INF: How to Remove Attached Tables





SHARREDDB.TXT - 6/4/93
