Reverting Unwanted Changes

In my previous article, I wrote about the benefits of using file diffs with version control to pinpoint exactly what changes were made to a form in Access.

The only way to know for sure what changed is to directly compare it to what was there before you started editing the form. And that's where version control comes in.

With version control, all I have to do is export my Access objects to text files, and then compare the new version of my form to the latest revision from my repository. The Diff format does the hard part for me.

Undoing Unwanted Changes

At the end of that article, I posed the following question:

This is great if you saved something you wanted to save. But what if you don't want to keep the changes you saved?

Luckily, rolling back unwanted changes is one of the key benefits of version control.

There are two basic steps to restore an object using my approach to version control in Access:

Revert to a previous version of the exported object
Import the object back into the database

A practical example

Let's say that I have a report open in design view. I don't remember making any changes to it, but when I try to close the report, Access prompts me to save my changes.

Knowing that my code is under version control, I simply click [Yes] to save my changes. I then export my Access objects to text files and use the TortoiseHg commit tool to see what changed.

As it turns out, I changed some things I shouldn't have:

I did not intend to make these particular changes. I better roll them back.

Step 1: Revert to a previous version

The left side of the TortoiseHg commit tool shows the names of the files that have changed. When you right-click on the name of the file, a context menu appears. Before I actually revert the file, I'll use [Ctl]+[Shift]+[C] to copy the file path (you'll see why in a minute). Then, I'll right-click and choose "Revert...":

First, copy the file path. Then, revert the uncommitted changes.

Step 2: Load the reverted file into Access

This second step is unique to Access. In most programming languages, each source object is saved in a separate file. Thus, you need only revert that file to restore the previous version.

With Access, however, all of the source code is contained within a single .mdb or .accdb file. Before we can save our Access code with version control, we need to export the objects to individual files. Of course, changing those exported files won't have any effect on our Access application.

The only way for those files to have any effect is to import them back into our application. In most cases, that involves the undocumented LoadFromText function.

In the first part of Step 1, I copied the file path. I did that to save time in this step.

To import the reverted file into Access, I execute the following line of code in the Immediate Window of the application whence the report came:

LoadFromText acReport, "01_TaxCert", "M:\Repos\TaxColl2k\01_TaxCert.report"

Note that with LoadFromText there is no need to remove the existing object before performing the import (as opposed to the File.. > Import file... process in VBA or the External Data > New Data Source > From Database > Access process in the main editor).

With no warning, LoadFromText will forcibly overwrite any existing object with the same name.

Refining the process

With some simple Autohotkey scripts, we can automate the process even further. I'll share some of those tips in a future article.

Image by Pete Linforth from Pixabay