Installing and Updating Access Applications
So you've created an Access application and you want to distribute it to users. That's great. How do you actually do that?
Well, there are a bunch of different options. I won't go into detail on any of them here. This post is mainly to provide you with a jumping off point for further research. If there is interest, I may go into one or more of these options in greater detail in a future article.
Options I Have Used
In the first part of this article, I will cover a few of the approaches that I have personally used.
Windows Batch File
This is nothing more than a .bat
file that lives in a network folder. Its contents often look something like this:
copy /Y "G:\Updates\MyFrontEnd.accdb" "C:\Users\Public\Documents\MyFrontEnd.accdb"
pause
There are only two steps:
- Copy an updated front-end file from the network to the local computer
- Pause the script to troubleshoot any copy operation errors
The batch file approach is the ultimate "quick and dirty" solution. It will get the job done, but there are definitely better ways to do it. If you will be developing Access applications professionally, you need something more advanced.
Inno Setup
Inno Setup is a free (not open-source) script-based installer for creating Windows setup packages. Creating a basic installer is pretty easy. Doing more advanced things is possible, but it has a relatively steep learning curve.
That said, this is an extremely powerful platform that has a lot going for it. I think it works best if you start small with a simple installation package and build it up over time. To save yourself a lot of headaches, put all your Inno Setup script files into version control.
This is my go-to solution. The true power of this solution is in building a generic template file and then creating multiple unique installation packages with just a few lines of configuration.
For example, here are some sample of my Inno Setup scripts. Each one of these creates a digitally-signed, executable installer. Most of the magic happens in the referenced AccessTemplate.isi
file, not shown below. To paraphrase Fermat, it's a brilliant bit of Inno Setup code but it won't fit in the margins of this particular article.
OFAC
[ISPP]
#define ThisVersion "10.3.31"
#define AppName "OFAC"
#define SourceFile "L:\Installs\OFAC\OFAC.mdb"
#define IconFile "C:\ProgramData\GandB\OFAC.ico"
#define IconName "OFAC.ico"
#define AppUID "{{3320E776-FEDC-BA09-9A90-F90B3A06008B}"
; Include external dependencies
#define IncludePDFCreator
#include <..\AccessTemplate.isi>
TaxClaim2k
The thing that I love the most about Inno Setup is that it is Version Control-Friendly. The AccessTemplate.isi file referenced above has undergone over 100 changes over its ten-year lifetime. Each one of those changes is meticulously documented within its version control repository.
There is also amazing signal-to-noise ratio in the individual application install scripts. There is a section at the top of each script with six application-specific variables that are common to every setup file. Then, there is a section where I list any external dependencies. All the complexities of installing these common dependencies are captured in the AccessTemplate.isi file.
The final section is where I list any dependencies that are unique to that particular application. Once the same dependency appears in two applications, its code gets moved to the AccessTemplate.isi file.
The template file also includes all the necessary code to digitally sign and timestamp all of our installer packages.
Can we make a build in one step? Check √
AutoHotkey
I wrote an AutoHotkey script that we install on most of our clients' workstations. The script is my own personal take on an automatic front-end updater (see below for a commercial version you can purchase from Tony Toews).
The script is compiled into an executable and placed in the Windows Startup folder (one more feature built into the AccessTemplate.isi file above). When the script starts up, it checks a network folder for a list of potential Access applications that may be installed on the local computer.
For each match, the script goes and checks a different network folder for an empty file with a specific file-naming convention: {ProgramName}.{ComputerName}.upd. If the .upd file exists, the script does nothing.
If the .upd file is missing, the script copies the front-end file down from the network to the local computer. It then creates a new .upd file using the prescribed naming convention.
To update an application, we copy a new front-end file to the network and then move all the .upd files into an archive folder. The next time the user logs on, the script will note the missing .upd file and automatically grab the new version of the program.
The script sits in the notification area of the taskbar. This allows a user to force the download of a clean version of the front-end, which is a handy way to resolve the occasional corruption error that can occur in front-end files.
PDQ Deploy
If I want to silently and remotely install an application on many machines, I turn to PDQ Deploy. With PDQ Deploy, I can create a single package that installs the required Access Runtime version (if required) and then installs our Access application. I can nest packages to install multiple Access applications to a single machine. This is useful when setting up new machines in a department where every workstation needs the same three or four Access applications.
PDQ Deploy has a very capable free version. I suggest you start there. I've been happily paying $500/year for their pro version, though. If you are using the free version, are happy with it, and are thinking about stepping up to the pro version, you won't be disappointed.
Options I Have Not Used
The items in this list all appear to warrant further research. They look like they would be good fits for Access deployments. I've never actually used any of them, so I can only recommend that you do your own research and ask around.
SSE Setup
I first read about SSE Setup in this UtterAccess post: SSE Installer - Setup Conditional install for 32 bit / 64 Bit Access. Unlike most generic Windows installers, it has specific support for installing Access applications:
SSE Setup is an ideal installer to deploy Microsoft Access databases. It is one of the only installers that actually has had significant work done in it to make deploying Access databases a breeze.
This is a freeware tool for non-commercial use. Commercial use requires purchasing a license for $200 (as of the time of writing). I can tell you that I have waaaay more than $200 of development time in my Inno Setup solution. If I was starting from scratch today, I would definitely give this software a try.
Advanced Installer
Advanced Installer is another commercial package that includes support for building Access application installers: How do I create an installer for an Access Database?
This looks like an extremely capable piece of software, and its commercial pricing reflects that. It currently starts at $500 per seat for its lowest paid option. However, the tool has a Freeware option that does allow for commercial distribution.
No license is necessary when using only freeware features in "Simple" projects. Install packages created using these features can be freely redistributed and used both in commercial and non-commercial purpose (subject to EULA).
NSIS
The Nullsoft Scriptable Install System is the only open source option for creating Windows installers in this list (Inno Setup is completely free of charge but it is copyrighted software). I assume this is similar in its approach to what Inno Setup offers, but I've never actually used the software so I can't say for sure.
Auto FE Updater
The Auto FE (Front-End) Updater is a well-established tool for updating Access front-end files from 16-time former Access MVP Tony Toews. I know Tony only from his prolific posts on many of the Access support forums. Based on his demonstrated Access knowledge, I assume this is a solid product.
It appears to be targeted mainly at installation environments with a local area network. Of course, that's a very common scenario with Microsoft Access, so there's a good chance it would suit your needs that way.
That said, it does not appear to create traditional installation packages that will install and register external dependencies. This seems more like an improvement over the Windows Batch File approach I discussed above.
Total Access Startup
Total Access Startup from FMS appears aimed at networked enterprise environments. The software allows the administrator to centrally manage Access deployments from one location on the network. The program creates shortcuts that you email to users for launching your application.
One of the key features of this option appears to be its support for multiple versions of Access. Each of your applications can specify which versions of Access it will run on. If the user is missing a required version of Access, they will see a friendly error message. Total Access Startup also supports localization, meaning you can replace the text shown on its screens with your own, whether that be different English text or another language entirely.
Windows Installer
The only officially recommended installer for Access applications is Windows Installer:
for Access versions 2013 or later, you can use Windows Installer or search for a third-party program that creates installation packages.
I followed the above link and was met with pages and pages and pages...and pages and pages of documentation but no simple set of steps to actually build an installer.
I imagine you can do just about anything if you follow this approach. But I don't even know how much it costs--if anything--to use the Windows Installer approach. I've got lots of other options that work great for me. Best of luck to you if you go this route.
No Longer Available
SageKey Software
For a long time, SageKey Software appeared to offer the premium Access packaging and deployment tool. I never used it because I was happy with the Inno Setup templates I had developed. However, it had phenomenal support for side-by-side installations with multiple versions of Access. It was the only solution I knew of that handled the pesky "Installing Access..." message that used to pop up when switching between different versions of the Access Runtime on the same machine.
Unfortunately, the current Access versioning situation is so convoluted, they finally just gave up trying to keep pace. Here's a link to the page where it looks like they now sell the source code to developers who relied on it in the past: StartAccess Source Code.
UPDATE: This article was updated on 1/11/2021 to include the section on FMS's Total Access Startup, based on feedback from former Access MVP Tom Wickerath.
Image by Free-Photos from Pixabay