Deployment

Creating Pre-packaged Software with Microsoft Access

Microsoft Access is a poor choice for creating pre-packaged software applications. But does it really have to be that way?

Mike Wolfe

Jul 21, 2022 • 7 min read

Selling pre-packaged Access applications is way more difficult than it needs to be.

I mentioned this on an Access mailing list recently and got some push-back on my underlying assumption that one would use Microsoft Access to create pre-packaged applications in the first place. And the commenter was correct! Microsoft is clearly not marketing or targeting Access as a way to create Commercial, Off-the-Shelf (COTS) software.

As the commenter went on to say, using Access to create COTS software is akin to the carpenter with only a hammer to whom everything looks like a nail.

And, I'll admit, there's more than a little of that going on here. I think Microsoft Access is a tremendous tool that is irrationally undervalued by the programmer community at large. But his response got me thinking.

Why, exactly, is it so hard to create and sell pre-packaged Microsoft Access applications?

It Doesn't Have to Be This Hard

The more I thought about it, the more I decided there is no inherent reason that it should be so difficult to create pre-packaged software with Access.

After all, most desktop applications today rely on some sort of runtime:

C# (.NET framework)
Java (Java Runtime Environment)
Electron (Chromium)

Thus, the fact that Access requires a runtime makes it more mainstream than not.

The Individual Challenges

I decided to put together a quick list of all the things that make creating and distributing Access applications as pre-packaged software difficult (and, in some cases, needlessly so). Over time, I hope to dive deeper into the individual challenges with solutions, workarounds, or feature requests for how we can overcome them.

All Applications Run Under the msaccess.exe Process

While .NET and Java applications run under a runtime, they can at least do so under their own executable. Not so with Access.

For example, we created custom General Ledger and Accounts Payable applications for one of our clients. But if you look in Task Manager, you won't see GL.exe and AP.exe. Instead, you'll see msaccess.exe and msaccess.exe. If you turn on the Command Line column, you'll see that one is msaccess.exe GL.accdb /runtime /excl and the other is msaccess.exe AP.accdb /runtime /excl.

Assigning custom application icons can help with this situation, but it's not perfect. For example, if you have icon grouping enabled in Windows, those two applications will get grouped together under one icon or the other.

The Application File Gets Modified When It Runs

That GL.accdb file that I referenced above is modified as soon as it opens.

This has a few side effects:

You can't verify it via checksum
The application file occasionally gets corrupted and must be replaced
Anyone who runs the application must have Modify rights to the file
You can't code-sign the front-end application file

You Can't Fully Protect the Source Code

Sure, you can "compile" your front-end file into an .accde, but that is not the same as compiling to machine code as you would with something like C++.

Instead, the code gets "compiled" into P-code (a type of intermediate code similar to the Common Intermediate Language [CIL] of the Common Language Runtime languages; e.g., .NET). This "compiled" code can be reverse-engineered into the original source code. To my knowledge, though, only Wayne Phillips (of vbWatchdog and twinBASIC fame) has actually succeeded in performing this feat.

However, Wayne has strict ethical rules around that service and will only perform it for companies that can prove it is their intellectual property (a common example is an in-house employee that creates an .mde or .accde then leaves the company).

Personally, I don't think this is a big deal. And, in fact, I don't even bother compiling to .accde for my own prepackaged Access application.

No Simple or Obvious Way to Create an Installer

Years (and years) ago, Microsoft used to sell an Access developer's package that included a "Package and Deployment Wizard."

Honestly, I found the wizard underwhelming. And having to go through a whole manual process every time I wanted to release a new version of my applications was a complete non-starter for me (and also goes down as a failure on the 12-point Joel Test).

I've built a custom Inno Setup installer, but it took me dozens of hours and many years of real-world testing to create it.

SageKey Software used to sell a tool that would create a standalone installer with an Access runtime that could peacefully coexist with any other form of Office or Access on the client computer. Unfortunately, Microsoft made such a mess of the Office/Access/Access Runtime deployment situation that the company finally just threw in the towel on their software:

.With all of these changes, limitations, roadblocks, the Access Deployment Wizard cannot guarantee the trouble free, reconfiguration free install that it once could. Without the guarantee of that level of service, SageKey Software is not able to, in good faith, keep offering the Access Deployment Wizard.

I wrote more about the options available for Installing and Updated Access Applications.

You Need to Roll Your Own Updater

There are many third-party tools available for updating your front-end Access applications.

Auto FE Updater (by former MVP Tony Toews)
Front-End Updater (by former MVP Richard Rost)
List of options on Stack Overflow (answered by Renaud Bompuis)

However, most of them assume that you are performing your updates on a private LAN. If you are going to distribute a pre-packaged Access application, you'll need some other way to deploy program updates that does not rely on the availability of a network file server.

One exception to the above rule is Kevin Bell's newly-launched service which does work over the internet. You can check that out at AccessAppLauncher.com. It's a commercial service, but the pricing is very reasonable.

You Need to Roll Your Own Licensing Scheme

Many commercially successful desktop applications use a freemium licensing model these days.

A limited version of the application will be given away for free, with premium features requiring a paid license to gain access to them. PDF XChange Editor and PDQ Deploy/Inventory are two applications that follow this model.

While I assume there are third-party libraries that integrate with Java and .NET to provide this kind of functionality as a drop-in solution, I'm not aware of anything like that for Microsoft Access.

The Third-Party Ecosystem is ... Lacking

The above issue is a microcosm of a much broader problem: the barren landscape of third-party tools for the Access developer.

There are a few notable exceptions:

fmsinc.com (Luke Chung's suite of Access developer tools)
everythingaccess.com (Wayne Phillips's vbWatchdog and vbMAPI add-ins)
MZ-Tools
Rubberduck VBA
AccessUI.com (Kevin Bell's Ribbon and Tree Builder, et al.)

What Access lacks is a full-fledged package manager, such as NuGet for .NET.

And even if such a package manager existed, it's not clear there would be enough quality packages available to necessitate such a manager. But maybe if there was a package manager, more people would create and share packages. Classic chicken-and-egg situation.

I'd like to think twinBASIC could change things in this regard, but it is quite an uphill battle.

I suppose this is more of a nice-to-have feature, rather than something whose absence makes it needlessly difficult to prepackage Access applications. That said, it would be a really nice thing to have.

The Bugs...Ye Gods, the Bugs!

I'm not sure where to begin.

There have been so many recent Access bugs that I've had to dedicate an entire area of my site to keep track of them all: Bug Alert.

And I'm not the only one. Over at devhut.com, Daniel Pineault has a whole section dedicated to tracking and reporting on Access bugs, too: MS Access Bugs.

There's not much we can do about this one. Advising customers to stay away from Current Channel updates can help, but it's not a panacea. Many bugs are caused by Office or Windows security updates and those get applied immediately to all supported versions of Access, not just the Current Channel.

The only thing I'll note here is that bugs happen in other software ecosystems, too. I'm not a Java or .NET desktop developer, so I have no idea how comparable the situation is in other languages.

Everything Else

I know there are other challenges I'm leaving out, but I've already gone farther into this topic than I intended.

If you have other challenges–or solutions to some of those I listed above–please let me know in the comments below.