Similar app versions

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?
Derek BrownMDAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dale FyeOwner, Dev-Soln LLCCommented:
how do you define "different customer versions"?
Derek BrownMDAuthor 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
PatHartmanCommented:
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.
Maximize Customer Retention with Superior Service

The IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more to help build customer satisfaction and retention.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Derek BrownMDAuthor 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 LLCCommented:
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
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
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.
Derek BrownMDAuthor Commented:
Thanks all!!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.