Managing Application Updates

By | September 21, 2019

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.

Schema Updates

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

Category: Access to SQL Server Migration

About Kent Gorrell

Over twenty years experience as a Business Analyst and Project Manager, then as a Development Manager Database Architect and finally Developer. I specialise in Custom Business Applications written in MS Access and SQL Server because these are the fastest and most cost effective development tools to create applications to run businesses for both Desktop (Local Network) and Cloud.