Copying the front end is the easy part

If you look after an Access application for more than a handful of people, you've probably built your own updater by now. A batch file behind the desktop shortcut. A version table in the back end that the front end checks on startup. Maybe a tool you bought. And it works—most of the time.

Then it's Monday, a little after eight. The new release went out on Friday. The first call comes in: “It won't open for me.” Your coffee goes cold while you figure out why three people are stuck and everyone else is fine.

You already know the rule: split the database, keep the data in a back end on the server, and give every user their own copy of the front end. It's the right setup. It also means every release has to land on every PC.

Getting a file from a share onto a desk is easy, and every updater does it. What breaks is everything that has to be true on that desk before the new copy will run.

• The old copy is still open. Someone left the application running overnight. The swap fails, or it hits a file that's in use.
• The bitness doesn't match. Controls and components that Access loads have to match the bitness of Office. A component registered only as 32-bit fails on a PC with 64-bit Office, and the other way around.
• The folder isn't a trusted location. Then Access won't run the application's code without a prompt. Trusted locations live in each user's registry. They don't travel with the file, so they have to be set on every machine—and in some companies, IT has locked the Trust Center.
• The release needs more than a file. ODBC drivers, data sources, the .NET runtime. Those usually take admin rights, which means a ticket with IT for every release.
• Nothing records what was installed. When a release turns out to be bad, there's no clean way back. You copy the old file around again and hope nobody opened the new one in between.

Turn those failures around and you get a short list. A deployment you don't have to babysit

• installs per user, with no admin rights;
• puts each version in a folder of its own and never overwrites the one that's running;
• detects the bitness of Office and registers the matching components;
• sets up the trusted location itself;
• keeps a record of everything it installed and rolls all of it back if a step fails;
• starts the installed version when the share is unreachable;
• accepts only releases that really come from the publisher.

That list was the spec for the Bootstrapper. IT deploys the starter once, as a signed MSI package. From then on, you save each release to the source folder. On the next start, the starter installs it in the user's profile, registers what the application needs, and opens it.

The starter is designed for both bitnesses: a single EXE that detects whether Access runs as 32-bit or 64-bit and registers the matching components. It works with Microsoft Access from Microsoft 365 on Windows 11. The current release doesn't support Windows 10, or PCs where AppLocker or Windows Defender Application Control restricts programs in the user profile. Access applications are what it's built for, and it launches any other program the same way.

If a release goes wrong, the previous version stays installed and starts from the settings window. Your users keep working while you fix it.

And Monday? The coffee has a fighting chance of staying hot.

Which configurations the current release supports, and where its limits are, is on the product page.

Are you shipping an Access front end today by script, email, or version table to more than a handful of workstations? Then the first step is a look at your environment: Office bitness, the app’s components, the policies on the workstations. After that you’ll know whether Bootstrapper runs there and what IT has to set up once. It doesn’t commit you to anything.

Bootstrapper: features, requirements, and booking a call · Rather talk first