There is always the question of "what is the best way to update/upgrade? And what happens when I do it?”

This best practice article is not intended to be documentation, as that already exists. It is only intended to list points to consider and answer frequently asked questions, for a Plant wide, server based Q-DAS system installation which should be updated.

Some of the basic considerations are the same as for a first installation!

Are all contacts available? Are the IT and database administrators informed and available if required? Are all logins known, where is the server installation, where are the databases, are the passwords available?

The question is whether it is "just" a patch, an update to a minor release, or an update to a new major release (e.g. V13 to V14).

The explanations will start with the easy ones.

Update to a patch

2 ways to update a patch, for 2 reasons: To test a patch, or to update all clients to a patch.

Testing a patch

To test a patch on a particular client, the folder containing the new version can be downloaded as "Update Package" and then be placed on the server:

And in the launcher, the user can then simply do a right mouse click on the software name, select the "change directory" option and adjust the path point to the new version:

Update all Clients

2 possibilities:

Use the "setup" for the new version on the server and select the option to automatically update "Launcher *.INI files" for all clients. This way, all client launcher files will get the path to the new application. Or, for a manual and maybe more gradual implementation of the update, an admin can use notepad to change all the launcher files (sometimes this is the preferred option for customers).

Update to a Minor Version

Example: Update from V14.0.2.x to V14.0.4.x 

The main idea is the same as for the patch. Is it a test or a full update. The main question from customers here is: Do we have to update the databases when updating to a minor release?

The answer is "YO" (YO being a combination of Yes and nO). It depends. In most cases it is not technically necessary to run the existing products. But sometimes there is a new structure and new content. New content in the form of new texts, new defaults in the configuration database, new content in the form of new tables for new functionalities. In case of doubt, an update of the databases is required in the same way as an update to a new major version.

Upgrade to a new major version

Even a major upgrade (e.g. from V13 to V14) is no longer a problem since the new installation folder structure was introduced in V12. The author of this page has often been in customer meetings, and while the customer is still making all his comments about how dangerous an upgrade is, and backup, and what is broken, and while the customer is still talking, the main upgrade has been done. To the customer's astonishment.

The most important information (and customer questions) about upgrading a server-client deployment (coming from V12 or V13) is summarised here:

What happens when you upgrade the server deployment:

• The server installation of the old version and directory structure remain as they are. New elements of the new version are simply added. (new application files are placed in a parallel folder, other files such as new default settings for the Plant folder in the new _Template_V14 folder, new INI files are added in new folders).
• ALWAYS backup the "DatabaseLinks" folder (FireDAC.INI) though, before updating the application in the server. (there will be different selection options during the installation of the new version regarding which database connections to use ....)   
• And, of course, the "old" server installation directory and current databases should be backed up beforehand.
• The old version on the server can still be started at any time.
• The clients of the old version can still be launched.
• The status of the old version has not changed.
• The Q-DAS Version listed in the Windows "Programs and Features" option will be updated to show the new version only.
• Do NOT actually UNINSTALL the "old" Version on the server- in case of an upgrade, it is the basis for the new version. (preventing users from using the old version - in time - can be done otherwise, for example by de-registering the old version's license). 

The database update must be performed after the upgrade. Follow the instructions in the manual.

New clients of the new version will need to be redistributed. However, this is a parallel installation. The old clients can still be launched at any time. Old version clients may be uninstalled.

All this means that if the server-client deployment has been installed in the classic way, an upgrade is not a problem and the software itself has various security measures built in. 

However, if required, a parallel world in the form of a test installation can be run after the new version has been made available on the server and BEFORE the new test clients have been distributed in the workshop. This can be discussed with the application engineer during the project.

Parallel usage, of both versions, old version and upgrade

Our Setup gives the possibility, to create a "parallel installation" inside of the "Share" installation directory structure. Yes. But:  NEVER make it your actual deployment plan to run both versions for good!  The ability to use the old and the new version in parallel is meant for during of the "cut over" time period to the new version only.  

After the upgrade, managers should check the new version. The old version will continue to run. Once the functionality has been confirmed, users can be told to use only the new version.