Test and Release
Each client has a person responsible for testing and then releasing new versions – The Client’s Project (or Application) Manager
This is important as it ensures that
a) the Client has the opportunity to test in their environment for critical use cases before THEY release
b) they share responsibility for any issues that may then arise in production
My Front Ends are designed to know when they are in a Test Environment and connect to test data (Be it Access or SQL Server)
The test data should be a recent backup from production.
When run against the Database for the first time, the Application will modify tables, fields, indexes and additions to Lookup tables.
And, if the Database is SQL Server, then Create/Alter scripts will modify or add Stored Procedures, Views and Triggers
In Development, I modify the Schema by adding new tables and fields to tables in the Application itself.
For Server Objects, I modify them in Management Studio and then copy the scripts to a table in the application
The Database Update is fully automated so when it occurs in Development, Test and then in Production the same outcome is assured.
No one needs to run any scripts or modify the database manually onsite
The new version is then released by the client by simply copying the new FE(Application file) to a folder on their server (in a pier to pier network just a dedicated machine)
I hard code this folder to be the \Distribution\ sub folder of their shared data folder but it could be anywhere where all users have read permissions
Usually this folder is where their shared Back End Access Database resides but is typically where documents are kept regardless of the BE so Read/Write privileges are required for the application to write pdf files for example.
Then when they open it in Production for the first time –
• The FE now knows it is in Production and relinks the tables views and Passthroughs
• When run against the BE for the first time, the FE will run the Database Update (if required)
• and increment the version
When users launch their FE,
their FE tests to see if it is the latest version and,
if an update is required, it automatically does the following
• shells out to a little Updater app
• closes their FE so it can be written over
and then the updater app (.accdb or accde)
• copies the new version from the server
• closes itself and
• restarts the new version of the application
This all works brilliantly
• No onsite maintenance is required for either an Access accdb BE database or SQL Server database
Apart from backups
and more importantly
• it empowers clients with the opportunity and responsibility to test before releasing a new version into their production environment