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:
-
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 user'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.
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 |
| 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 | |
| Control database startup | Add a custom title or icon to a database Bypass startup options when you open a database |
| Set important properties and options | |
| 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:
-
Strive to get the best performance out of your solution. For more information, see Help Access run faster and Microsoft Access Performance Tips to Speed up Your Access Databases.
-
Compact and repair the database. For more information, see Compact and repair a database.
-
Backup the database so you have an original and safe copy of the original database. For more information, see Protect your data with backup and restore processes.
-
Use the Database Documenter to print the design characteristics of database objects. For more information, see Document and print your database design.
-
Decide how you want to secure the file. There are several approaches you can take:
-
Add a security certificate to the database. For more information, see Show trust by adding a digital signature and Decide whether to trust a database. If you do this, decide how you want to control the Message Bar in your database. For more information, see Enable or disable security alerts on the Message Bar.
-
Use a trusted location to store the front-end database to avoid it being checked by the Trust Center or if you don't want it to open in Protected View. for more information, see Add, remove, or change a trusted location.
-
Encrypt the database file. For more information, see Encrypt a database by using a database password.
-
To make sure users cannot modify the design of forms, reports, or VBA code, consider using a compiled binary file (.accde).
-
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.
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.
-
From your Windows Desktop, right click and select New > Shortcut.
-
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.
Download the Access Runtime
Note: For Access 2019 Enterprise, do not download and install a runtime - doing so will replace your full version of Access with just the runtime. Instead, use the Office Deployment Tool to specify that the AccessRuntimeRetail product is installed.
To download the Access Runtime from the Microsoft Download Center, click the appropriate link for your version.
-
Download and install Office 365 Access Runtime
Note This Access Runtime also applies to Office 2019 Consumer licenses.
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.
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
-
Open the database that you want to package and sign.
-
Click the File tab and then click Save As.
-
Under Database File Types, click Package and Sign and then click Save As.
-
In the Select Certificate dialog box, select a digital certificate, and then click OK.
The Create Microsoft Office Access Signed Package dialog box appears.
-
In the Save in list, select a location for your signed database package.
-
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
-
Click File > Open.
-
In the Open dialog box, select Microsoft Office Access Signed Packages (*.accdc) as the file type.
-
In the Look in list, locate the folder that contains your .accdc file, select the file, and then click Open.
-
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.
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.
-
-
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.
ACE no longer requires a separate installation to interact with non-Office apps
TBD
Space
Space
Space
Space
Space
Space
Space
Space
Space
No comments:
Post a Comment