Working with multiple programmers on MS Access

Question

Would you recommend working with multiple programmers on an MS Access application?

One of our MS Access application has grown to the point where the number of changes (bug fixes) and new features can no longer be handled by one programmer in the requested time frame.

We are trying to introduce version control using the undocumented SaveAsText and LoadFromText procedures in VBA to make collaboration on this application possible. Unfortunately we have already run into problems loading modified forms and reports back into Access as a checksum is stored in every form text file.

Before putting time into building an import/export application to compile text files into an Access database, we would like to hear your recommendations.

Answer 1

Sounds like a terribly painful way to do team development. If you have any options for porting to another environment like VS2008 that would be my recommendation.

There is no easy way to work on Access as a team and even version control might be a bit tricky.

Answer 2

I think you should avoid this path at all cost, and try and persuade management into redevelopment.

It's a bitter pill to swallow, but this is going to need to be redeveloped sooner or later, and you are just saving them time and money.

Answer 3

Have look at this thread:

http://stackoverflow.com/questions/187506/how-do-you-use-version-control-with-access-development

Answer 4

Have you ruled out Visual Sourcesafe for some reason?

Answer 5

We were using Microsoft's own version control add-in for MS Access 2000/2002/2003 for about 5 years now, and I can't remember a single serious problem. Usability of this add-in barely deserves a "B", but it must be much, much more convenient than fiddling with any ad-hoc method involving manual or semi-manual exporting/importing of Access forms, modules, etc.

We were using VSS as a version control system all the time. No problems whatsoever. However, if you have some good reasons to avoid VSS, you may have some options:

• The version control add-in that we were using does not require VSS. Theoretically it can be used with any version control system that implements Microsoft Source Code Control Interface (MSCCI). For example, when we had to let somebody work on this project remotely, we used SourceOffsite by SourceGear. Access version control add-in worked with this third-party product fairly well (not without some quirks, but well enough). So, if your favorite version control system complies with MSCCI, you could try to use it.

• Now that Microsoft has this Team Foundation thingy, apparently there are other options to be used to integrate MS Access with version control. We did not explore this path, though. This article may be a good start for exploring it.

Hope this would be of some help. :-)

P.S. I am not a big fan of MS Access. In fact, I rather hate it as a platform for a user front-end. If I had a choice, I would run away from it yesterday. :-) However, I must admit that existence of this version control add-in is one of the few things that makes maintenance of our old Access+SQLServer project more or less tolerable. :-))

Answer 6

Following the direction provided by Yarik we settled on continuing developing in Access using the Access Add-in Source Code Control, the SVN SCC API Plugin by PushOk Software and Subversion. This stack provides us with seamless Access integration, full-backup and restore and an open version control system.

We had to install a hotfix to Access 2003 and make sure the default database file type matched our database file type to make it work.

We will continue to update this answer with our findings.