Deploy an Access application

Access provides a feature-rich platform for developing database applications. A database application is a computer program that provides both a way to store and manage data and a user interface that follows the logic of business tasks (application logic). This article discusses basic deployment planning, packaging and signing, deploying database applications, and the Access Runtime environment.

What do you want to do?

Plan for deployment

Before you begin, you should ask yourself the following questions about the way that the application will be deployed.

Should the data and the logic be separated?

You can create an Access application that combines data management and application logic in one file. This is the default application structure in Access. Combining data management and application logic in one file provides the simplest deployment method, but this method works best only if a few people use the application at the same time, and it involves some risk. For example, a user could cause data loss by unintentionally deleting or damaging the application file. In most cases, you should separate data management and application logic. This helps improve performance and reliability.

One way to separate data and logic is by using the Access Database command (on the Database Tools tab, in the Move Data group). This command splits your database application into two Access files: one for logic (a front-end) and one for data (a back-end). For example, a database called MySolution.accdb is split into two files called MySolution_fe.accdb and MySolution_be.accdb. You put the back-end database in a shared location, such as a network folder. You distribute the front-end file, one copy for each user, to their computers. You can even distribute different front-end files to different users. For more information, see Split an Access database.

Another way to separate data management and application logic is by using a database server program (such as Microsoft SQL Server) for data management, and Access for application logic. For more information, see Migrate an Access database to SQL Server.

Additional reasons for separating data and logic include the following:

What will the network environment be like?

Choosing the correct Access database solution for your network environment is a critical step to making it successful. Use the following guidelines to help you make the best choice for your needs.

Home network

If you only have a few users to share your Access database with, you can use a single database that each person opens and uses on a home network. For more information, see File sharing over a network in Windows 10.

Local Area Network (LAN)

A LAN is an internal network that usually has excellent performance, but is limited to a small geographical area, such as a single room, building, or group of buildings. When you have more than a few users sharing the database on a LAN, it’s best to split the database, store the back-end database in a network folder, and deploy a copy of the front-end database for each user.

Wide Area Network (WAN)

There are many possible configurations for a WAN, which covers an extensive geographical area. You may have multiple offices across a city connected to a public network, a leased line, or even satellites. Often, a Virtual Private Network (VPN) is used for secure remote access from the home or on the road. A simple way to understand a WAN is that whenever you are outside a LAN but connected to it, you are using a WAN.

Azure file shares

Azure file shares are not a separate type of network but provide a way to use file shares over a network without the need for a file server. However, using an Azure file share can introduce issues similar to those that arise when using an Access split database in a WAN.

Warning Avoid using an Access split database in a WAN or with Azure file shares because performance can be slow and databases may become corrupt.

The supported alternatives to using a split database in a WAN or on Azure file shares are: