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

Deploy an Access application

Understand and download the Access Runtime

Create an installation package

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:

  • Data integrity and security     If you combine data and logic in one file, the data is exposed to the same risks as the application logic. An Access application that uses separate logic and data files can help protect data integrity and security by leveraging NTFS security features on network folders.

    Access Users must have read, write, create, and delete permissions to the folder where the front-end file is located. However, you can assign different permissions to the front-end file itself. For example, you may want to assign read-only permissions to some users and read/write permissions to other users.

    Your application may require further security options, such as the ability to control which users have access to particular data. In this case, you could use SQL Server or SharePoint to store and manage your application data, and use Access to provide the application logic.

  • Scalability    An Access file can have a maximum size of 2 gigabytes (GB). Although 2GB is a substantial amount of text data, it may be insufficient for some applications, particularly applications that store attachments in database records. If you separate the data and the logic, your application can accommodate more data. If you expect that users will store a large volume of data, you might consider using more than one Access data file.

    You should also review the Access program specifications for other scalability information. To learn more about Access specifications, see the article Access specifications.

  • Network capacity    If multiple users will need to use the application at the same time over a network, data corruption is more likely to occur if the data and logic are combined in one file. Moreover, if you combine the data and the logic in one Access file, you cannot optimize the network traffic that Access generates. If multiple users will simultaneously use your application over a network, you should separate the data and the logic, either by using two or more Access files, or by using a database server product for data and Access for application logic.

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.

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

There are three supported ways to use Access in a WAN:

  • An Access database with linked tables to SharePoint lists.

  • A front-end Access database connection to a backend SQL Server database or Azure SQL.

  • Remote Desktop Services (RDS) (previously know as Terminal Server), which creates a virtual Windows desktop environment on a users’s client computer. RDS has several advantages:

    • No installation of Access or an Access database is required as users run the Remote Desktop (RD) client which is available on many devices.

    • Data transfer is minimized between the client and the server because RD is a thin client that efficiently streams just the user interface.

    • Users can still copy and paste data and print reports locally from the client computer.

    • RemoteApp can run just a single program such as a turnkey application for vendors or frontline workers.

    For more information, see Welcome to Remote Desktop Services.

Will users have Access?

If all of your users will have Access installed on their computers, they can open and use the application as they would any Access database file.

If some or all of your users will not have Access installed on their computers, you can also deploy the Access Runtime software to those users when you deploy your application. For more information, see Understand and download the Access Runtime.

Top of Page

Deploy an Access application

To deploy an Access application, you need to do the following tasks.

Prepare the database as an application solution

To lock down your solution, control navigation and startup, and set other important options, do the following:

Task

More information

Decide how users navigate the user interface: use a default form, create a switchboard, use a navigation form, or use hyperlinks and command buttons.

Set the default form that appears when you open an Access database

Create a navigation form

Customize the Navigation Pane

Show or hide object tabs

Featured Access Templates

Create and use a switchboard

Decide if you want to customize the Office ribbon and command menus

Create a custom ribbon in Access

Create custom menus and shortcut menus by using macros

Use the custom toolbars and startup settings from earlier versions of Access

Apply a consistent Office theme and background

Add an Office background

Change the Office Theme

Control database startup

Add a custom title or icon to a database

Bypass startup options when you open a database

Create a macro that runs when you open a database

Command-line switches for Microsoft Office products

Set important properties and options

Set startup properties and options in code

View or change the properties for an Office file

Modify regional settings

Change the Windows regional settings to modify the appearance of some data types

Tip    To be thorough, browse through the Access options dialog box (File > Options) and then click help for each tab. There may be additional options you want to control for your application solution.

Before you deploy

Before you deploy the front-end database, consider these best practices:

Decide which file format to use

There are four Access file formats that you can use when you deploy an application:

  • .accdb    This is the default file format for Access. When you deploy an application in this format, users have the most options to customize and navigate the application in whatever way they choose. If you want to ensure that users do not change the design of your application, you should use the .accde file format. In addition, a user cannot easily determine whether an .accdb file has been changed after you packaged it — to make this obvious, use the .accdc file format.

  • .accdc    This format is also known as an Access Deployment file. An Access Deployment file comprises an application file and a digital signature that is associated with that file. This file format assures users that no one has changed the application file after you packaged it. You can apply this format to a default format Access file (.accdb), or to an Access compiled binary file (.accde). For more information, see Show trust by adding a digital signature.

    You can put only one application file in an Access Deployment file. If your application has separate data and logic files, you can package them separately.

  • .accde    This format is also known as a compiled binary file. In Access, a compiled binary file is a database application file that has been saved with all of the VBA code compiled. No VBA source code remains in an Access compiled binary file. An .accde file prevents design and code changes, reduces the size of the database, and helps improves performance. For more information, see Hide VBA code from users.

    You can use the Access Runtime to open an Access compiled binary file. If the Runtime does not recognize the .accde file name extension, open the binary file by creating create a shortcut that points to the Runtime, and include the path to the compiled binary file that you want the shortcut to open.

    Important   Users can't open a compiled binary file by using an earlier version of Access than the version in which it was compiled if the earlier version doesn’t support a feature added in the later version. To resolve this issue, compile the binary file in the Access version your users have installed.

  • .accdr    This format enables you to deploy an application that opens in runtime mode. Deploying a runtime application can help you control the way that it is used, although it is not a means of securing an application. For more information about runtime mode, see the section Understand the Access Runtime.

Install and upgrade an Access front-end database

When you adopt a split database design, you need to distribute the front-end database to each user. To make things go smoothly, consider the following best practices:

  • Ensure that each user has the correct version of Access and that the front-end database opens in the correct version. Access also has 32 bit and 64 bit versions. Running the incorrect "bitness" can affect Windows API calls, DLL library references, and ActiveX controls. For more information, see Choose between the 64-bit or 32-bit version of Office.

  • Create an installation package for other files that may be required including database drivers, batch files for setup and configuration, and application-related files. For more information, see Create an installation package.

  • Provide a Windows desktop shortcut so the user can quickly run the Access solution. Include in the shortcut the folder location, a meaningful shortcut name, a description, and an icon. For more information, see Create a desktop shortcut for an Office program or file.

    Tip    Instruct your users how to Pin apps to the Start menu.

  • Determine an effective way to redeploy and replace the front-end database when updates are required and maintain versions of files to keep track of changes. For example, you could add VBA code to check for new versions and upgrade automatically even before users start the application.

  • When you create an ODBC connection by using a DSN file that contains the connection string, that DSN file also needs to be installed on each client machine. Another approach is to create a "DSN-less" connection in VBA code to eliminate the need for a DSN file. For more information, see Using DSN-Less Connections.

Top of Page

Understand and download the Access Runtime

To deploy Access applications that can run without an installation of Access on a user's computer, you can distribute them along with the Access Runtime, which is available for free from the Microsoft Download Center. When you open an Access database by using the Access Runtime, the database opens in runtime mode.

Runtime mode is an Access operating mode in which certain Access features are not available by default. Some of these unavailable features can be made available in runtime mode, however.

Which features are not available in runtime mode?

The following Access features are not available in runtime mode:

  • Special keys    Keys such as Ctrl+Break, Ctrl+G, and the Shift key to bypass startup options in the database.

  • Navigation Pane    The Navigation Pane is not available in runtime mode. This helps prevent users from accessing arbitrary objects in your database application. Only those objects that you expose to users — for example, by providing a navigation form — can be opened while using runtime mode. You cannot make the Navigation Pane available in runtime mode.

  • The Ribbon    By default, the Ribbon is not available in runtime mode. This helps prevent users from creating or modifying database objects, and from performing other potentially harmful actions, such as connecting to new data sources or exporting data in ways that you do not intend. You cannot expose the default Ribbon tabs in runtime mode. However, you can create a custom Ribbon, and then associate that Ribbon with a form or report. For more information, see Create a custom ribbon in Access.

  • Design view and Layout view    Design view and Layout view are not available for any database objects in runtime mode. This helps prevent users from modifying the design of objects in your database application. You cannot enable Design view or Layout view in runtime mode.

  • Help    By default, integrated Help is not available in runtime mode. Because you control what functionality is available in your runtime mode application, some of the standard integrated Access Help may be irrelevant to people who use your application, and could potentially confuse or frustrate them. You could create your own custom Help file to complement your runtime mode application.

How can I simulate runtime mode?

You can run any Access database in runtime mode on a computer that has the full version of Access installed. To run an Access database in runtime mode, do one of the following:

  • Change the file name extension of the database file from .accdb to .accdr.

  • Create a shortcut to the database with the /Runtime command-line switch.

    1. From your Windows Desktop, right click and select New > Shortcut.

    2. Enter the location of MSAccess.exe, the location of your database, and the /runtime command qualifier. For example:

      "C:\Program Files\Microsoft Office\MSACCESS.EXE" "C:\MyDB.accdb" /runtime

    For more information, see Create a desktop shortcut for an Office program or file.

Does runtime mode make my database more secure?

Although runtime mode limits the availability of navigation and design features, you should not use runtime mode as the primary means of securing a database application. On a computer that has the full version of Access installed, it may be possible for a user to open a runtime database application as a regular database application (that is, with all features available) and then to change the design or perform other unwanted actions.

Even if you deploy your database application only on computers that do not have the full version of Access installed, it is still possible for a user to transfer the application to a computer that does have the full version of Access installed, and then open the runtime database application as a regular database application.

Top of Page

Download the Access Runtime

To download the Access Runtime from the Microsoft Download Center, click the appropriate link for your version:

No purchase is necessary to download, use, or redistribute the Access Runtime, and there is no limit on the number of users to whom you can distribute the Runtime.

Top of Page

Create an installation package

There are several approaches you can take depending on the version of Access.

Use a general installation package (Access 2013 or later)

for Access versions 2013 or later, you can use Windows Installer or search for a third-party program that creates installation packages.

Package and sign an Access database (Access 2007 and 2010)

In Access 2007 or 2010 it's easier and faster to sign and distribute a database. After you create an .accdb file or .accde file, you can package the file, apply a digital signature to the package, and then distribute the signed package to other users. The Package-and-Sign feature places the database in an Access Deployment (.accdc) file, signs the package, and then places the code-signed package at a location on the user's computer that you determine. Users can then extract the database from the package and work directly in the database (not in the package file). For more information, see Package Solution Wizard Overview.

Note: The feature described in this section packages an Access file and applies a digital signature to the package that helps indicate to users that the file is trustworthy.

Remember these facts as you proceed to create and sign a package:

  • Packaging a database and signing the package are ways to convey trust. When you or your users receive the package, the signature confirms that the database has not been tampered with. If you trust the author, you can enable the content.

  • The Package-and-Sign feature applies only to databases saved in the .accdb file format.

  • You can add only one database file to a package.

  • When you package and sign a database, all of the objects in the database file are code signed, not just macros or code modules. The packaging and signing process also compresses the package file to help reduce download times.

  • After the database is extracted from the package, there is no longer a connection between the signed package and the extracted database.

  • If you use a self-signed certificate to sign a database package and then click Trust all from publisher when you open that package, packages signed by using your self-signed certificates will always be trusted.

  • If you extract the database to a trusted location, its contents will be automatically enabled whenever you open it. If you choose a non-trusted location, some database content may be disabled by default.

The following sections explain how to create a signed package file and use the database in a signed package file. To complete these steps, you must have at least one security certificate available. If you don't have a certificate installed on your computer, you can create one by using the SelfCert tool or obtain a commercial certificate. For information about security certificates, see Show trust by adding a digital signature.

Create a signed package

  1. Open the database that you want to package and sign.

  2. Click the File tab and then click Save As.

  3. Under Database File Types, click Package and Sign and then click Save As.

  4. In the Select Certificate dialog box, select a digital certificate, and then click OK.

    The Create Microsoft Office Access Signed Package dialog box appears.

  5. In the Save in list, select a location for your signed database package.

  6. Enter a name for the signed package in the File name box, and then click Create.

    Access creates the .accdc file and places it in the location that you chose.

Extract and use a signed package

  1. Click File > Open.

  2. In the Open dialog box, select Microsoft Office Access Signed Packages (*.accdc) as the file type.

  3. In the Look in list, locate the folder that contains your .accdc file, select the file, and then click Open.

  4. Do one of the following:

    • If you chose to trust the digital certificate that was applied to the deployment package, the Extract Database To dialog box appears. Go to step 5.

    • If you have not yet chosen to trust the digital certificate, an advisory message appears.

      Advisory message

      If you trust the database, click Open. If you trust any certificate from that provider, click Trust all from publisher. The Extract Database To dialog box appears.

  5. Optionally, in the Save in list, select a location for the extracted database and then, in the File name box, enter a different name for the extracted database.

If you are unsure of whether to trust a certificate, the article How to tell if a digital signature is trustworthy provides general information about checking the dates and other items in a certificate to help ensure that it is valid.

Top of Page

Expand your Office skills
Explore training
Get new features first
Join Office Insiders

Was this information helpful?

Thank you for your feedback!

Thank you for your feedback! It sounds like it might be helpful to connect you to one of our Office support agents.

×