It’s important to have a process to deploy an application to a client or customer. If you don’t have a process in place, Whatever method you use is not reproducible every time.
I prefer to automate my deployment process as much as possible. I’d prefer to just copy a new file to a repo somewhere that the customer client checks and auto-updates when a new version is available. I built in some routines to help look for a new file and load it using Access JumpStart.
But if you are starting from scratch, where do you begin?
The best place to start is simply to document your current process in a document somewhere. Then make sure you follow the instructions to the letter each time you deploy to make sure you don’t forget any steps.
The reason to automate this with a script is because inevitably someday you’ll be in a hurry and you might miss a step. Or you’ve handed over the documented process to a new employee, and they might be in a hurry and they might miss a step.
Either way, human error is far more likely than a script error.
This is why I create a script to deploy my app. Now, the deployment in many cases is simply copying the current file to a new folder, like a MakeLive subdirectory, and then modifying that file’s properties and option tables to match the live customer environment. This allows me to simply copy the file from the MakeLive subfolder to a folder on the customer’s network.
I have another customer whom I create a complete setup file for using the program SSESetup which I highly recommend if you need to deliver a setup file for your customer to run. Usually this would be because they did not give you access to their network or perhaps because you have a suite of Access programs you need to deliver all at once. Whatever the reason, I still run a script beforehand to prepare all the files for the live environment prior to handing them over to SSESetup which will package them for installation.
SSESetup has built in configurations for Microsoft Access and can either ensure they have the correct office installation, or even install different versions of your application depending on whether they have 32 bit or 64 bit Access installed.
It can even install a free runtime version of Access for them and/or install needed ODBC drivers. Certain functions require administrative access for the users, like installing ODBC drivers.
In any case, using scripts to deploy your application makes it much easier and is more professional, providing a consistent experience for the users of your application.