Similar app versions

Derek Brown
Derek Brown used Ask the Experts™
on
This could be my stupidest ever question: I have an access 16 application in a number of different customer versions. At the moment when I modify some code I have to note it and then copy and paste it into the other versions. Is there any way to avoid this?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Dale FyeOwner, Dev-Soln LLC
Most Valuable Expert 2014
Top Expert 2010

Commented:
how do you define "different customer versions"?

Author

Commented:
It's usually just customer preferences which need changes to code forms and reports. But when someone points out a necessary change for example I sometimes forget to check for null values as well as values. Then I have to fix the code open 6 different versions and alter them all. That's probably the simplest change
Distinguished Expert 2017

Commented:
Sounds like you have not split the database so please confirm.  Is the app in TWO separate databases?  The FE (front end) database that contains all forms/reports/code/queries/macros  and links to tables.  The BE (back end) database contains ONLY tables.  The BE is stored on a shared network drive and each user has his own copy of the FE.

If these are separate clients that have their own sets of data and do not reside on the same LAN, the app should still be split into FE and BE.  

Among other things, this setup allows you to completely replace each users copy of the FE without disturbing their data.

If the users are all on the same LAN and sharing the same BE, we can help you with an automated distribution method for the FE.  For different clients, there isn't any way to automate the process completely but you would still only maintain one master copy of the FE and distribute a new version to all customers when you make any change to the FE.

Regarding customization - if these are different client companies, you may have company name and address and other customization for forms and reports.  Those should all be table driven and set up by each customer.  Do you think Quickbooks maintains a separate code base for each of its millions of customers?  No it doesn't.  All customization must be table driven and under the control of the customers or you should not implement it.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Most Valuable Expert 2012
Top Expert 2014
Commented:
Depending on the type of changes, you may have to do exactly what you're doing now - change each "version" as needed. And while I agree with Pat that you should have some sort of common repository for changes, in many cases that's just not realistic. Quickbooks can do that because if they lose you as a customer, they'll just pick up another. If you lose one of 6 clients, that could be a big hit to your revenue stream.

You might consider setting up version control for things like this, and branching off for each of the clients. There was a discussion about a system for Access a while back, and I believe many are using Subversion with this:

https://dev2dev.de/index.php?lang=en

You can branch off for different builds of your database, and make specific changes for ClientA, and different ones for ClientB. You can also make changes to the root and push those out to all branches.

Subversion (or any version control system) can be tough to learn, but once you get your system in place it can be a real timesaver.

Author

Commented:
Thanks Scott I will look into that Link.

The databases are split. The changes required by users are not data related. We already have forms that clients fills in for their own variables. Things like simple company name address etc for reports down to individual ways of manufacturing their products are all variables. The simplest required change would be a form laid out to suit their needs. But some want additional features buried in reports  with supports and sometimes simply more fields in forms that no one else wants. I can do all this of course but then when a change is needed that would benefit all clients I have to apply it individually to each version. Pain in the rear and open to emissions or errors.
Dale FyeOwner, Dev-Soln LLC
Most Valuable Expert 2014
Top Expert 2010

Commented:
One option would be to create a library database which contains all of your common functions and subroutines.  It means deploying an additional accde file with your applications.  This is generally quite easy to do, but would only be for general use procedures and functions, it would not apply to changes to form or report logic.

Dale
Most Valuable Expert 2012
Top Expert 2014

Commented:
One of my main income streams comes from creating add-ons for large ERP systems. These are "locked" systems, in that we cannot make changes to the actual interface. Quite often one of the ERP customers will need specific functionality, and myself (or someone else on the "custom" team) will create an interface that does what they want.

This "add on" methodology is a good fit for situations where you have varied users, with many different scenarios. You keep the core functionality the same for all, but provide the addons only for those clients who need it. Some of the ERP systems also have the concept of "custom" objects - like a custom form that can be called in place of the native one. the custom form can be one that you've created that inherits from the main form, but is customized to the specific customer.

Most of these things are done in languages other than Access, of course.

Author

Commented:
Thanks all!!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial