Source Code Control, or other best practices

[GBalcom]

So, I've been reading about how source code is a great idea for developers in general, including Access projects. FMS shows a link on their site about it here: https://www.fmsinc.com/MicrosoftAccess/taking-over/index.html about half way down the page.

The thing is, I believe VSS is now extinct.

Does anyone else use some type of source control? If not, I'm interested in hearing any best practices to keep versions straight, during frequent interruptions and development delays.

 

[HiTechCoach]

I agree that Source code control and versioning are very important. It is critical for multiple developer projects and commercial software.

The design of Access does not play well with multiple developers working on the same application at the same time. Version control is not well supported either.

From my 25+ years’ experience as a professional developer, most Access applications are worked on by a single person at a time. They are also rarely sold as a commercial solution. That is why I think there has not been a lot of demand for Source Code Control or version control for Access. I can understand why Microsoft could not see value in investing money to develop Source Code Control for Access 2013 and later.

I don't think Access was ever designed or intended to be a development platform for commercial applications. Visual Studio was design for professional developers to create commercial applications.

I develop and sell commercial applications. Some are built with Access. I do use source code control ad version control with all projects including Access.

Are you considering creating and selling commercial software?

 

[GBalcom]

Hi Boyd,
Sorry for the delayed response. No, I'm not going to be selling any software. (At least not yet) But I have several small applications I've built that our company relies on daily. The largest has about 6,000 lines of VBA code. I'm really just looking for known best practices at this point. I want to ensure I can recover from any issues as fast as possible.

It may be helpful to go over my current process. I have a "master development" copy of each application. When I decide to add a new feature or fix a bug, I'll make a copy of that .accdb file as a static backup, such as "App B-B4 2-24-17 development". Then I'll proceed with development on the master copy. After development and simple testing, I'll release a new version by creating a .accde file from the master copy. I'll save this to a location for my users. (I forgot to mention this is all for the front end of a split db)

I have FMS Total Access Detective, so I can compare old copies of the application to a newer one if I need to find a bug, etc.

My main question is this; given above, would I benefit from some kind of source code control? If it has merit, I'm willing to try and pursue it.

 

[mjdemaris]

GBalcom: is the FMS software worth it?

 

[GBalcom]

GBalcom: is the FMS software worth it?

I tend to think so...I bought the developer suite for Access 2010 about 2 years ago, and just recently updated to the ultimate suite for Access 2013. I'm still sorting through all the new features I have available to me, but I really like the Access Startup, Sourcebook, and Analyzer. The detective is pretty neat too.

Keep in mind, I'm a part time developer, so I'm always looking for ways to improve my own output, and save time.

 

[The_Doc_Man]

In essence, most source control routines are based on some form of difference engine and baseline. The question of change monitoring is then to track changes by playing forward all edits to the last approved version, and then running the difference engine to generate yet another difference file to take you from the last approved version to the next version. And if you like it and choose to save it, you use a routine to "bless" that change.

In essence, each change-file defines a new version of the targeted module. When you have multiple modules, each with an independent version ID, you have reached a point where your product has a CONFIGURATION comprised of the individual approved versions of the member components.

Using this concept and the command line DIFF command with some options, it becomes possible to define configurations in a script. I have not done this myself, but about 30 years ago on some old DEC equipment, a source code manager script was available using their command line scripting language.

Here is the catch that folks quickly found. If you get a code manager, you have to have the self-discipline to actually use it - because the damned thing slows you down horrendously vs. working by yourself as a developer and just taking good notes. It is always the case. With a development team, the "too many cooks" aphorism takes on practical meaning and becomes the justification for code management. For a single developer? Much tougher call.

 

[mjdemaris]

Well, I am also a part-time developer, and now have two access databases running, though they are far from finished. There are things I see that could be improved, users always come up with some else they would like.
There are still some things I would like to do, just don't quite have the knowledge yet. And I have at least two more databases that I would like to develop. After that, I hope to move to SQL Server and develop in C#...but that is going to take some time.

I try to take notes in OneNote, but even then, I find that I sometimes lose track of various notes and things. And they tend to be a bit unorganized...

So, I wonder if I can sell the purchase of FMS software to my boss,

More like 3/4 time developer.

 

[The_Doc_Man]

So, I wonder if I can sell the purchase of FMS software to my boss

First convince yourself. As long as it is speculative, your boss might very will choose to not bet on the results of speculation.

 

[GBalcom]

In essence, most source control routines are based on some form of difference engine and baseline. The question of change monitoring is then to track changes by playing forward all edits to the last approved version, and then running the difference engine to generate yet another difference file to take you from the last approved version to the next version. And if you like it and choose to save it, you use a routine to "bless" that change.

In essence, each change-file defines a new version of the targeted module. When you have multiple modules, each with an independent version ID, you have reached a point where your product has a CONFIGURATION comprised of the individual approved versions of the member components.

Using this concept and the command line DIFF command with some options, it becomes possible to define configurations in a script. I have not done this myself, but about 30 years ago on some old DEC equipment, a source code manager script was available using their command line scripting language.

Here is the catch that folks quickly found. If you get a code manager, you have to have the self-discipline to actually use it - because the damned thing slows you down horrendously vs. working by yourself as a developer and just taking good notes. It is always the case. With a development team, the "too many cooks" aphorism takes on practical meaning and becomes the justification for code management. For a single developer? Much tougher call.

Doc_Man,
Thanks for the rundown. It is great to get a summary of how these systems actually work. I'm still on the fence. I think with my current tools and setup, I'd probably be fine moving forward as is. I certainly don't want to slow down my workflow, as my development time is always limited.
What I'm particularly curious about is if it SCC would save time during a bugfixes. It still would seem you'd have to go through and determine what actually caused the bug, then when it was introduced, and actually fix it.

At this point, I could likely do that already by going through the .accdb files I've saved at different stages in the project. But honestly, I'm more likely to figure out what caused the bug within the current "master development" .accdb, and simply fix it, release a new .accde and move on with life. Not sure if I'm missing anything here. Sure, it'd be nice to go back and document the when, where and how. But who has that time? And to what benefit? (If I'm off base here, please tell me)

 

[Lightwave]

It may be helpful to go over my current process. I have a "master development" copy of each application. When I decide to add a new feature or fix a bug, I'll make a copy of that .accdb file as a static backup, such as "App B-B4 2-24-17 development". Then I'll proceed with development on the master copy. After development and simple testing, I'll release a new version by creating a .accde file from the master copy. I'll save this to a location for my users. (I forgot to mention this is all for the front end of a split db)

That's pretty much how I set mine up mine. Works fine for pushing out the latest version to users. I should say most of my users use rdp to get to the front end so I only need to push the latest runtime out to one location.

Working with other developers is definitely trickier - I haven't really been anything but the sole developer of VBA for my Access applications so I haven't had to tackle that. I am however working on a project at the moment that involves writing extensive amounts of SQL to take information out of one system and into another. The vendor has asked us to write the SQL in MS Access and there is so much of it I can't do it all myself. We have split the writing of SQL to modules of the target application within which we will not be looking at the same tables and which developers can go off on their own branch. I have then created a shared online database application (ASP.NET and SQL Server) where we can share and compare SQL code. At the end we will merge all of the SQL code but working at moment. Its possible that we will not actually need to merge the code as the MS Access is just temporary suitcase to hand to the vendor before he loads it into an Oracle database.

Many of the modules have very similar structure so having the ability to see others SQL is an advantage plus we need to finish at about the same time. So everyone can see how everyone else is getting on.

Thinking if we were working on the VBA we would have to have agreed areas of the application within which to focus. Need to have clear guidelines on things like Global Variables and Global Functions. In principle with good communication I don't see why its not possible.