Last Update 2006 / 03 / 05
Microsoft Access and Source Code Control Systems
current as of May 28th 2005
I have no intention for this being an extensive overview about Source code control and version management software (abbreviated as SCM (Software Configuration Management)-Systems in the following text). I rather want to describe my own impressions and experiences with some of these systems, especially of how well (if at all!) they work together with Microsoft Access, since I got the impression this is a topic that is rarely dealt with elsewhere. The main problem in this context is not finding a suitable SCM-system, but finding a comfortable way to interact with this Version-Control-System from within Access. (This is mandatory as an Access-Application is just one single file when viewed in the file system.)
It looks like the majority of Access-Developers is not particularly interested in professional source code control and version management. On the other side most of the SCM-Products'vendors don't show much interest in Microsoft Access either. Confronted with this situation, I had to make most of the experiences described in this text by myself.
I don't want to explain the basic benefits of source code control, because if your interest in this text shows that you'll probably know them already. Besides that, is has taken quite a lot more time than I expected to write (and translate!) this article anyway.
Before we really start with the technical part, I want to thank Mark Dörbandt, who, at a point where I had given up this topic in frustration, revived my passion and motivation to delve deeper into this matter and to write this article. I want to thank my dear friend Jonas Strube as well, who helped me quite a lot by reviewing the English translation of this article.
Visual Source Safe
Visual Source Safe is the obvious solution for the Access-Developer who wants to use source code control. Visual Source Safe and a suitable plug-in for Access are included in the developer edition of Microsoft Access. The installation process is straightforward and usually runs without any problems. After the installation an experienced developer can start right away, using source code control without lengthy configuration issues.
If this was all there is to say about Visual Source Safe this article would have ended here, assuming I even had ever thought about writing it. - But unfortunately it isn't. Visual Source Safe has some severe disadvantages. The main disadvantages I encountered so far are: VSS requires direct access to the repository in the file system, which means every developer working with it requires access to a Windows network share where the repository is located. On the files system level you have to grant write-access to the full repository to everyone who should be able to change any tiny bit of code within the repository. Encryption of the communication between client and server is not possible by VSS itself. The communication-protocol of Source Safe is quite bloated, making it virtually impossible to access a VSS-Repository by a slow dial-in connection. Branching and merging of projects under source code control is a major pain.
Many of the requirements of most of today's software development projects can not be met by Visual Source Safe. Today we work in distributed teams where there are developers outside the corporate network who require access to source code. Sometimes we have large teams and everyone being able to accidentally delete the whole repository form outside VSS states a significant risk. Additionally, in larger projects sooner or later arises the need to branch, and later merge, the source. If you have to go through such lengths as you have to with VSS to do this, you may be tempted to do some silly things instead…
But, well, I for myself have been using Visual Source Safe for more than three years now, even if I am the only developer on a particular project. I have worked with Source Safe in small teams with up to five developers as well, where Source Safe met at least the basic requirements.
So utilizing Source Safe is definitely a possible solution for source code control in Access development projects, and in many projects it may even be the best solution because of the low price (if you bought a the developer edition of Access you already have a copy of Source Safe) and because of the ease of use. In larger projects with diversified development teams the difficulties with code sharing and administration might be quite challenging.
Tested Version(s): Visual Source Safe 6a and 6c
PS: A short while after the initial publication of this article the first public beta of Visual Source Safe 2005 has been released on the Microsoft website. It looks like VSS 2005 is going to address most of the issues with Source Safe described in this article. But unfortunately this beta release is not working with the plug-in for Microsoft Access. Therefore I avoided the effort of testing VSS 2005 Beta so far.
Source Off Site (VSS)
Source Off Site is not by itself a Source code control system, but it is a communication service that wraps around a Visual Source Safe repository. On one machine the Source Off Site Server is installed, combined with a Source Safe Client which has direct access to the file system where the Source-Safe-Repository resides. Every developer connects via his own Source Off Site Client, using TCP/IP to communicate with the SOS-Server that accesses the VSS-Repository by using the Source Safe API. The SOS-Server is implemented on the Microsoft .NET platform and has 128 Bit encryption built in.
The SOS-Client integrates well with the SCC-plug-in for MS Access and in my, rather short, test I wasn't able to discover any problems with the integration of SOS into Access as well as with SOS as a whole.
Tested version(s): 4.0.2 released May 2004
As well as Source Off Site, Vault is developed and distributed by Source Gear. So it isn't really surprising that Vault does integrate equally seamless into Microsoft Access. Even with my rather extensive evaluation of Vault I wasn't able to discover any serious flaw in the product when using it from within the Microsoft Access IDE.
The GUI of Vault is intentionally kept quite close to the layout and functionality of source safe, except for some improvements. If you are already familiar with Visual Source Safe, this reduces the effort to get used to Vault tremendously.
One of the things special about Vault is that it uses no traditional repository in the file system. Instead, it stores the source code in a Microsoft SQL Server Database (or MSDE). The server's communication part is handled by a .NET-Webservice. The communication protocol between client and server does not transfer the whole documents every time but only a small delta, containing the recent changes to the document. This results in a quite impressive speed of the system especially when used over low bandwidth connections.
The Server component requires a Microsoft Internet Information Server (IIS) with ASP.NET and Access to a Microsoft SQL Server. The SQL-Server has not necessarily to be installed on the same machine as the Vault-Server. The Vault Sever and the Vault client are completely consisting of Microsoft .NET (Version 1.1) technology. All network communication between client and server can be encrypted using the SSL-Support delivered by the IIS.
Vault is completely free for one single user! So combined with the MSDE it is a great low cost / high efficiency system for a single developer.
Tested Version(s): 3.0.1 and 3.0.7 (April 2005)
Jalindi Igloo (CVS)
Jalindi Igloo is a wrapper around the win-cvs client for the well known cvs-source-code-control-system. In MS Visual Studio (6.0 and .NET) Jalindi Igloo works as a plug-in for the IDE via the MS-SCC-API. The basic features work well in Visual Studio, nearly without problems, but since I haven't tested Jalindi Igloo really extensively, I can't conclude if Jalindi Igloo is really suitable for productive use in Visual Studio. Fact is, Jalindi Igloo is still a beta product and is said to have some bugs when used in VS. This may be quite a limiting factor as the active development of Jalindi Igloo has stopped and the source code for the SCC-API-Parts of this solution is not available.
Unfortunately Jalindi Igloo does not work in Microsoft Access at all!
Tested Version(s): 1.1d (April 11th. 2002)
PushOK CVS SCC proxy (CVS)
As you surely expected when reading the name, the CVS-SCC-Proxy is not a complete SCM-System but, like Jalindi Igloo, a plug-in supporting the MS-SCC-API and wrapping around the win-cvs-frontend to the cvs-source code control system. Yet, unlike Jalindi Igloo the PushOK-CVS-SCC proxy is working quite well and stable as SCC-plug-in in Visual Studio as well in Access.
Much to my regret, I encountered an unpleasant bug while testing the plug-in in Access. Access-Objects with long names (more that 40 characters), and Objects whose name contains blanks get lost when creating a new Access Database from the cvs-repository. As the objects are created as text files in the local working folder, there is a workaround to this issue by importing the text files manually into Access with the undocumented LoadFromText-function. After that you can work (checkout/checkin) with these objects without further problems, but nevertheless this issue is a serious showstopper.
As the CVS-SCC-proxy is still under active development and the development team addresses even Access-specific problems, we hope that this issue will be fixed in future releases of this product is justified. (The bug has been reported to PushOK).
Even in spite of said issues, the PushOK-CVS-SCC-proxy is a promising product that, considering the low price, deserves some attention by any Access Developer looking for a SCM-Solution.
Important Update: After not commenting on my bug report concerning the issue mentioned above for several weeks, PushOK informed me recently that this issue has been addressed. The bug is completely fixed in Version 2.0.2 050419!
Tested version(s): 1.2.040806 (August 2004), 2.0.2 050419
The flagship of SCM-Solutions concerning power as well as concerning the price is, with no doubt on my part, Perforce. No other system offers so many features as Perforce. For that reason one should calculate some more time for getting used to this system.
Especially the concept of client-workspaces is something that requires a bit of time to get used to it. But you may deem it quite valuable as soon as you got used to it, if you expect the capability to work offline from your SMC-Solution. The list of features of perforce is that long, that I don't want to deal with particular details. But one lacking feature I want to mention, Perforce, as well as many other systems, has no built-in encryption for network communication. So if you want to use perforce when working over an unsafe network (the internet) you should definitely use some other way like a VPN or a SSH-tunnel to secure the communication.
While testing perforce from within Visual Studio as well as from within MS Access I wasn't able to detect any problems. Perforce integrated well into the IDE and was able to complete all operations I could think of without any dismay. But I received word from Karsten Pries, who has discovered a similar problem with missing Access-Objects that I have described regarding the PushOK-CVS-SCC-Proxy. Much to my regret I don't have a working perforce installation right now to analyze this problem in any more depths.
Nevertheless it is quite remarkable that there is a free Demo-Version of Perforce that is working with up to two named users and up to two client-workspaces without any further limitations.
Tested Version(s): 2003.2 (Nov. 2003)
VSS.NET is, even if the name would let one expect that, no product from Microsoft, but it is developed by DBM-Cosulting. This product mainly is a webservice that does work similar to Source Off Site as a wrapper around Source Safe and has to be installed on a web server (IIS) that has direct access to the VSS-repository. Access to the repository from the client workspaces (the developer's machines) then has to go via that .NET-Webservice. On every machine where someone should work with VSS.NET there has to be the VSS.Net client installed, that can interact with the SCC-API..
The VSS.NET Server as well as the VSS.NET client are based on the Microsoft .NET Framework, which has to be available as system requirement on the server as well as on the client.
The configuration required for the web server-machine looks quite adventurous to me, especially when looking from a security-aware viewpoint. There ist no encryption mechanism for the network communication integrated into the product and although I guess, it should be possible to use the HTTPS-Encryption of IIS for the connection to the webservice, there is nothing mentioned about that in the documentation. For these reasons any connection to a VSS.Net server from beyond the corporate network is only feasible via VPN.
My personal evaluation of VSS.NET was very disappointing. In Visual Studio 6 as well as in Access any use of VSS.NET resulted in crashing Exceptions within shortest time.
Tested Version(s): 1.67 (Oct. 2003, the last version available!)
Of course there are quite a few other SCM-Solutions, which I hadn't had the time to test until now. I do hope that I will be able to extend my tests and this article to some more SCM-Systems.
Important information for Access Developers.
Let me close this article with important information for Access Developers: Access does not support the SCC-API by itself, but needs a plug-in for this. Regarding Access 97 to Access XP, that plug-in was included in the Developer Edition of Access. But for Access 2003 you can (have to) download that plug-in directly from the Microsoft Website at http://www.microsoft.com/downloads/details.aspx?FamilyID=2ea45ff4-a916-48c5-8f84-44b91fa774bc&displaylang=en
Please direct any feedback top this article to firstname.lastname@example.org.
© 1999 - 2005 by Philipp Stiefel