What's the Purpose of an Access Version Control Add-in?

Access version control add-ins are not a replacement for Git, Subversion, or Mercurial.

What's the Purpose of an Access Version Control Add-in?

Outside the Access development world, nearly all software developers rely on version control systems to manage changes to their code over time.

However, within the Access community, adoption of version control is surprisingly low. This divergence feeds the stereotype that Access developers are not "real developers" like those building solutions in more traditional programming languages.

The reality is that Microsoft Access makes implementing proper version control very difficult out of the box. Unlike text-based code files, entire Access applications are stored in single monolithic binary database files. This structure provides almost no affordances for tracking granular changes over versions.

Fortunately, several Access add-ins have been developed that can overcome these challenges by integrating version control workflows. These tools export Access application components like forms, queries, and modules into individual text-based code files. The files can then be committed to a version control system like Git, Subversion, or Mercurial to track changes. Later, the components can be synced back into Access by re-importing from version control.

Today, we'll explore the key role that Access version control add-ins play in making version control with Access possible.

What Makes Version Control Difficult for Access

There are a few key reasons version controlling Access applications is difficult:

  • Single Large Binary File Format
    • Access stores all components like forms, reports, etc in one monolithic file.
  • Hard to See Discrete Changes
    • Binary files don't show line-by-line code changes like text files.
  • No Built-In Support
    • Developers must rely on third-party software to make Access compatible with version control systems.
  • Global Identifier Case Changes
    • When it comes to case-sensitive version control systems like Git, VBA's case-changing "feature" leads to false positives when identifying code changes.
  • Lack of Awareness
    • Since it's not a common practice, the topic rarely comes up on Access forums where many developers learn new techniques.

Benefits of Component-Based Version Control

By far, the single biggest impediment to version control in Access is its binary file format.

To be practically useful, version control requires converting as much of your application's design and logic into individual text files.  Doing this provides many advantages:

  • Convenience: You can manage changes to specific forms, reports, and queries independently.
  • Transparency: View code differences for each component.
  • Efficiency: Reduced repository file sizes (modern version control systems store only the changes between versions, not snapshots of each version).
  • Speed: You only have to export or import those components that changed.

The Role of Access Version Control Add-Ins

The key to making version control work with Access is to break down the single binary .mdb or .accdb file into individual text files representing the forms, reports, and modules.

Luckily, Access provides us with a way to do that via the hidden and undocumented methods SaveAsText and LoadFromText.  Those two methods make version control possible, but they still don't make it easy.  When we talk about version control add-ins for Access, we're mainly talking about systems that make it easier to do three things:

  1. Export Access components to individual text files (via SaveAsText)
  2. Import Access components from individual text files (via LoadFromText)
  3. Determine which components to export or import (via secret sauce 😉)

That's it.

NOTE: The actual versioning of your application's contents will be managed by the same set of generic version control systems the rest of the development world uses, such as Git, Subversion, or Mercurial.

Add-in Options

As I wrote earlier, there is no built-in option for integrating your Access application with version control systems.

You have a few options:

Roll Your Own

I spent dozens (if not hundreds) of hours over the past fifteen years building my own solution to this problem:

Putting It All Together
I expanded on the original decompose.vbs script. The code below is the culmination of more than 50 individual changes and tweaks over 10+ years.

Buy a Commercial Tool

There are a few options that I am aware of.  I have never tested them.  However, I do know Philipp Stiefel well enough to safely assume that his offering–Ivercy–is likely both reliable and well-written.  And I know Ben Clothier well enough to safely assume that if he uses Oasis-SVN, it must be good.

Ivercy (from Access MVP Philipp Stiefel)

Ivercy - Seamless source code control integration for Microsoft Access
Ivercy - Source code control integration Add-In for Microsoft Access 2007 - 2019

Oasis-SVN

DEV2DEV
OASIS-SVN, Versionsverwaltung für Microsoft Access.Version control with Microsoft Access.

Use an Open Source Add-in

I've personally used Adam Waller's Access Version Control add-in (msaccess-vcs-addin).  I like it so much, in fact, that I'm slowly migrating my own Access application repositories from my solution to his:

GitHub - joyfullservice/msaccess-vcs-addin: Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system.
Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system. - joyfullservice/msaccess-vcs-addin

Conclusion

Access version control add-ins are not a replacement for Git or Mercurial.

Instead, their role is to act as a bridge between your application and the version control system.  In this way, they are the middleware that makes it possible to integrate Access applications into generic version control systems.  

All original code samples by Mike Wolfe are licensed under CC BY 4.0