These rules are intended as a guiding philosophy. If I'm getting closer to meeting this vision, I know I'm moving in the right direction.

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.

SaveAsText will export queries to text files, but calling those files "human-readable" is a stretch.

Another potential source of bugs is changes to the structures of our tables. This includes both local tables and linked tables that reside in our back-end.

While we can use the VBA user interface to display the references, we can't rely on that approach if we want to automate exporting our Access binary file to text files. Luckily, there is a solution.

Anything that can lead to a bug in your software belongs in version control. That includes local tables with design-time data.

So, how can we compare those database properties? By iterating through the database's .Properties collection, of course. Here is some sample code from my modified decompose.vbs script.

Before we can use a DVCS with our Access application, we need to convert the binary Access file into a series of text files. The best place to start (and where my journey began) is with this StackOverflow answer.

Using version control is the most impactful change you can make to improve the quality of your Microsoft Access applications. Here is a quick list of just some of the benefits you gain using version control.

I believe without a doubt--even knowing what I know now--that I made the right decision at the time. If I could go back to 2009 and do it over again, I would still go with Mercurial. If I were starting from scratch in 2020...that's a different story.