My Access Tips for Custom Microsoft Access

Application Development

by Matthew V Carmichael

Need Help?

My Tips



Deploying an Access Application over a Local Area Network (LAN).

For deploying over a WAN click here.
(If the server where the Access files are stored is not physically located in the same building as the client PC using it, then it is likely the environment is a WAN.)

To deploy updates over the Internet check out my Web Updater function.

I have tweaked my deployment methods for years and feel that the outline I have listed here works best (the majority of the time). Trust me, this solution will make supporting your custom Access application much easier.

  1. Split the database into a front-end/back-end application.
  2. Save the front-end application as a mde file (or ade for adp files).
  3. Share the database - create a folder on a network share. The following files should be placed in the folder.
    • Application data file (back-end - .mdb)
    • Application mde file (front-end - .mde)
    • Batch file (used for startup - .bat)
  4. Use a batch file to deploy the front-end mde file on each users local PC.

Too often novice developers skip step 4. Skipping this step can only lead to frustration and headaches that many developers learn the hard way.

Check out the development and production environment I suggest to ensure that both the developer and users can work effectively.

Split the Database

Splitting the database is a must when deploying Microsoft Access applications.


An mde file offers many advantages and is excellent for deployment.  Increased performance, source code protection, and securing objects are some of the benefits gained by using mde files.   This file format locks down the application by disabling the user interface for creating/modifying forms, reports, and modules. 

        About mde files More Info ..

        Creating mde files More Info .

In my own experience I have resolved reoccurring database corruption issues by using an mde in place of an mdb file.   In one specific instance I was using a traditional mdb file in a mixed Access environment.  Several users had Access 2002 installed on their workstations while others had Access 2000.  At times my mdb file would decompile at runtime and certain functionality would not work properly.  After several failed attempts to resolve the issue, I decided to save the mdb file as an mde format.  This resolved the issue and ever since I have been committed to deploying mde files whenever possible.

Sharing the Database

Placing the database on a network share will allow multiple users to use the application.  Here are some additional tips to consider that may help in supporting the application and increasing performance.

        Share a database. More Info ..

        Link tables by UNC rather than mapped drives. More Info ..

        Put the application in the root of a network share. More Info ...

Batch File (for startup)

I find it more convenient to launch an Access database using a batch file instead of using a shortcut. So rather than creating a shortcut to an Access database on the users PC, I create a shortcut to the batch file.

Advantages of using a batch file

  1. The batch file requires no software other than Windows to run.
  2. It can deploy the mde front-end file locally.
  3. Local folders can be created if they do not exist.
  4. Easy to deploy updated front-end.
  5. Reduce user’s downtime (a major plus).
  6. Easy to create, implement and support (another major plus).
  7. Multiple command lines can be written to support multiple Access versions or installation locations.
  8. Easily add, change, and revise the logon process without having to go to each PC to install updated files and edit shortcuts.
  9. Easy new user setup – email them a shortcut to the batch file with instructions on how to save it to their desktop.
  10. Use windows commands to provide additional automation such as drive mapping, printer mapping, font installation, and more.

Below is a sample batch fie. Copy the script to notepad and place it on the server (as a .bat file). Then create a shortcut on the desktop to the batch file. The script can be secured by assigning Read/Execute NTFS permissions to the file. Edit the script to meet your needs (file locations, names, etc). The Pause line is for testing purposes; remove it when you put the script into production.

rem Check for local file - create directory and copy file if not present.
if not exist C:\MyDB\MyDatabase.mde mkdir C:\MyDB

Rem updates local copy with server file
xcopy "\\Server\Shared\MyDatabase.mde" "C:\MyDB\MyDatabase.mde" /y

Rem Launch application if in MSACCESS.EXE is in Microsoft Office XP folder
if exist "C:\Program Files\Microsoft Office XP\Office10\MSACCESS.EXE" start /max "MSAccess" "C:\Program Files\Microsoft Office XP\Office10\MSACCESS.EXE" "C:\MyDB\MyDatabase.mde" /wrkgrp "\\Server\Shared\MyDatabase.mdw"

Rem Launch application if in MSACCESS.EXE is in MS Office folder
if exist "C:\Program Files\MS Office\MSACCESS.EXE" start /max "MSAccess" "C:\Program Files\MS Office\MSACCESS.EXE" "C:\MyDB\MyDatabase.mde" /wrkgrp "\\Server\Shared\MyDatabase.mdw"


Deploy Front-end locally

Installing the front-end application on each user’s PC will increase the performance of the application.  Each user works within their own copy of the application front-end which links back to a central back-end data file located on the server.  Advantages of this method are:

  1. Increased Performance.
  2. Less chance of corruption in front-end.
  3. Developers can use temporary tables in front-end to quickly compile data.
  4. Updates can easily be delivered to user.

Novice developers quickly learn that they cannot make design changes in their Access applications while users are using it.  A simple task, such as expanding a field on a report, requires the developer to have excusive access to the application.  This requires the developer to notify and ensure all users close out of the application so the changes can be made.  This tedious task is eliminated by locally deploying the front-end file.  The developer can make changes to the master mdb file and then create a new mde file.  The mde file is placed on the network share (since each user has their local copy, the one on the server can be overwritten because no one is in it) and using my batch file example, the new updated file is copied to the user’s local machine at next logon.  So if the developer needs to make a quick change, once the mde file is created, all the user needs to do is log out then back in.  Simple, fast, and effective!

Back-end changes would require users to be completely logged out of the application.  Back-end design changes are best done at the beginning/end of the day, when users are out of the application, or should be scheduled.

Additional Tips

Here are some additional tips from FMS, Inc. that I use for managing deployment and increasing application performance.

Using the User Roster to Check for Users in a Database. View Tip

Verify Linked Tables in Your Application.View Tip

Increase Performance of Linked Databases. View Tip

Set table Subdatasheet Name Property to [None], or explicitly specify the name. View Tip

Also Check out

Tips from FMS, Inc.

Microsoft Access Performance FAQ