7 reasons to use source code control for Microsoft Access development

by Philipp Stiefel, originally published April 2^nd, 2016

Photo by Steve Richey used here under CC0 licensing

In this article I'm going to elaborate the reasons I use source code control when working on a Microsoft Access project. If you know about source code control already, most of this will probably not be new to you. Nevertheless, you might gain some additional insight in this topic from reading things from my personal point of view.

These seven reasons are ordered descending from most important to least important. – But that is just my opinion and you might put them in a different order.

1. History

Using source code control creates a speaking history of your code. Every significant change is logged in your version control history (as long as you check-in/commit it of course). All version control systems allow for a commit message or comment to be added to each commit/check-in. Please follow my advice here, and use this extensively.

How clearly the history speaks to you, depends on the effort you put into your check-in-comments or commit-messages. If you want to and your version control infrastructure supports this, you can force everybody on your team to enter a meaningful commit message or even add a reference to a work item/task in your task tracking database.

In the end it's up to you, how much effort you want yourself and your teammates to put into each commit/check-in. I personally rather err on the side of too much than too little. A couple of seconds on every commit might save your team hours down the line. If you have to figure out why and when something in the code was changed from one implementation to another and which files exactly were affected by this change, you will get the time spent on the commit message/comment repaid a thousand times.

2. Single objects/files are instantly "diffable"

One benefit based on the versioned files of your project is the ability to easily compare different version of a file. With an appropriate DiffTool you can visualize every difference between two versions of a file. This is extremely helpful, if you are tracking down a bug that was found in a new version of your project, but did not exist in an older version. You will be able to spot tiny changes to a file that would be hard to find otherwise and hence find the cause for a bug as the one just mentioned. - This feature saved me uncountable hours of debugging.

Sometimes you might come to the conclusion that the newer version of your file is messed up beyond repair. You then can simply roll back the previous version of the file with just a couple of mouse clicks.

3. Labeling/Tagging of Versions

Source code control systems enable you to Label distinct versions of your project. Think of this like putting a paper clip around several documents of a distinct version.

This is mainly a higher level of history organization within your repository. Each file may have lots of versioned changes. From a high level perspective, a single version does not matter too much. But from time to you want to mark a particular state of your whole project or even several related projects (within a folder hierarchy in the repository). Using Labels or Tags this state in time of any number of files can be “clipped” together under a meaningful name. This marks a significant milestone in your project history or a version that is released to your customers.

Sure, you can achieve the same, if you just develop with Access alone and archive the whole file on every significant milestone on a backup drive or in ZIP-Folder. 

The advantage of a source code control system is the fine grained level of insight and that you get. You can inspect individual files of a Label/Tag and compare them to another version of the same file under another label. You can easily find out exactly what was in a specific version and can compare the whole Label/Tag to another Tag of the same project. 

4. The source is available everywhere

The main reason I switched from Visual SourceSafe to Sourcegear Vault about ten years ago, was the feature to access the source code repository via the HTTP(S) protocol. Provided you have got the appropriate client installed on your development machine and your source code control server hosting the repository set up on a computer that can be reached via HTTP, you will be able to access your source code from anywhere in the world.

This helped me a lot when I was working on a project partially on site at the client and partially in my own office. No more tedious and error prone copying of different version of the code. I could just get the most recent version from the repository and with a quick glance on the history I would instantly know where I left of work at the other location, what I changed the last time I and which files (Access objects) were affected by those changes.

I admit, in the days of DropBox and OneDrive the easy availability of the source code everywhere is not that special any more. But it was back then when I started using source code control. And even today I find it much less intrusive, to have that explicitly directly integrated into a check-in than needing to either manually copy a database file to OneDrive or to worry about the state of the database being consistent if is synced automatically by OneDrive.

5. Coordination system for multiple developers

Without source code control…

If you work on one project with several developers, you might face a serious problem. How to keep the development efforts of each of them in sync? There might be projects where you can isolate the work of each developer to an extent that everyone works on his own stuff for weeks and you only need to integrate all the new stuff being developed in that time before a release. - Trust me: That is going to be a ginormous PITA.

Everyone would have to keep track on what he worked on and need to know what he changed during that time. Whatever manual system you conceive to manage this, there will be changes that get lost. Take my word for it.

If you really want to go down that road, I hope you have got some sort of automated testing in place with very high code coverage. - Oh, and keep in mind to integrate the changes to your tests as well.

I worked on huge projects like that in the past. I don't want to go down that road again. Ever.

With source code control…

How exactly you work as a team with version control depends on your SCC-System and the working style you prefer. So I will not go into too much detail here.

You will have one central repository in place that is authoritative on the state of your project’s code. It is your single point of truth.

You and every other developer on your team can get the latest version from there. It is relatively easy to see which files have been changed in the repository. You are able to easily compare your local state of the code with the repository

You can set up most SCC-Systems to lock the files you are working on (check out). The other people on your team are then able to see which files you have got checked out. As soon as you check in/commit changes to the repository, they become part of that single truth. Everybody else can get your changes and they will be able to see what you changed.

Working in a team will always have challenges and there always will be some overhead. Don’t make this worse by not using source code control.

6. Enforcement of coding rules, automatic tests and more

People are lazy, Developers even more so. That is part of the job. We automate recurring things, we do not like to write unnecessary stuff, we try to optimize whatever we do. That's a good thing. But sometimes it gets in the way. Our brain optimizes some minor details away that seem to be unnecessary at this moment. Like entering a meaningful check-in comment, like running the tests we are supposed to run before every check-in. - Our code would pass anyway, wouldn't it?

I have to admit: Guilty as charged. - We know better, but still we cut corners and omit things we know we should do.

So I am really glad that I can define validation rules, which are validated, whenever I do check-in code. The simplest example of this is a mandatory commit messages. I do that on all my projects however simple and unimportant they may seem.

But you can push it much further.

• You could automatically let the checked in code be validated against a set of coding standards rules.
• You could let your project be built automatically after every commit or in certain intervals. If it does not compile with all the changes include, there certainly is something wrong.
• You could automatically run a set of unit test on your project.

You have got lots of options with a centralized code repository, that would not have otherwise. At least not if you are working in a team of developers.

7. Current backup of individual objects/files

Any serious version control integration into Microsoft Access will manage individual Access objects (exported to files) rather than the whole binary Access database file. If you adhere to frequent check-ins in your workflow you will automatically have a pretty current backup of all your code at any time.

So while the version control workflow does need a little additional effort, you will get a detailed, fine grained backup for free without putting any more additional effort into it.

If you have set up your source code control repository on a server other than your local development machine, this backup will automatically be independent of any local storage. So even a total loss of your local machine due to a fatal disk crash, a virus infection, theft or whatever will not put the committed/checked-in source code at risk.

In fact, if it ever happens that my local working copy of the database gets corrupted beyond repair, I just delete it, get a new copy from the repository and move on. No big deal even in this fairly bad scenario. – If I had to do manual backup copies of my database for back, that backup would most likely not haven been that recent.

The multi-developer-myth

A common opinion is that you need source code control only if you are working with several developers on the same project. – Did you pay attention to the ordering above? For me the coordination of multiple developers in a team was only in fifth position.

So don’t get me wrong here. If you do work in a team, source code control is absolutely crucial. For me there is no way to go without it then. But I do work on a lot of projects as a single developer and even then there are absolutely compelling reasons to work with source code control. I consider some of the reasons even more important for me personally, because they apply even if you are not working in a team.

Conclusion

Source code control is an essential tool for my work as professional developer. I would not want to work without it.

If you are not using some sort of source code control, I hope you have got a good reason for not doing so. Otherwise I urge you to consider adding it to your set of tools you use on every project that spans more than a few days of work. - Here is some advice on choosing a SCC-System suitable for your work in Access.

Disclosure

I am the owner of the commercial product Ivercy, a source code control add-in for Microsoft Access. As Microsoft discontinued its add-in for source code control I needed an alternative so desperately, that I built my own.

Share this article: