When upgrading an Application you will need to consider whether you should do this as a Version or a Patch upgrade. Before making this decision, it is important to understand how these respective files will be processed by Windows Installer.
In essence, the Windows Installer will process a Version upgrade as a full installation rather than a patch. If an earlier version of the Application is located on the target system Windows Installer will uninstall the older version before installing the new version. If an earlier version of the Application cannot be located on the target system Windows Installer will proceed as if this is a first time install of the Application.
In contrast, the Windows Installer will process a Patch upgrade by first determining if the version of the application is eligible to receive the patch. If the application is eligible to be upgraded the changes contained in the patch are applied over the top of the existing application. The main advantage of a patch install over a version install is that a patch only contains changes to your application and therefore is usually much smaller.
Patches are typically designed to be uninstallable. Database changes may be complex to manage and uninstall so are usually delivered by a Version upgrade. Firstly, only one user of a database must uninstall the database changes so database changes are NOT backed-out automatically, you must specifically request it. Secondly, the standard uninstall processing provided by Windows Programs and Features does not provide a user interface, so you cannot request that database changes be backed out. You must use the command line instead.
By default a patch will not uninstall database changes. To do so or not to do so is a complex subject. If a Patch contains database changes you must fully inform your administrators how to back out the patch, or disable patch uninstall in the Deployment Tool package.
In order to uninstall database changes, misexec must be executed from the command line:
For example:
msiexec /package C:\DEV\TRUNK\WORK\X_WIN95\X_LANSA\X_APPS\PATCHDB\PATCHDB_v2.0.0_en-us.msi /uninstall C:\DEV\TRUNK\WORK\X_WIN95\X_LANSA\X_APPS\PATCHDB\PATCHDB_v2.0.0.5_en-us.msp SUDB=1 /qb
The parameters SUDB=1 /qb are optional. If they are not specified a dialog will be displayed and you can manually check Setup DB on.
Note, these are the functional steps. You must fully consider your specific situation before rolling back database changes. If a database is shared, only one of the users should rollback the database changes. All the rest perform the default uninstall of the patch from Programs & Features.
Alternatively, to back-out a Patch which contains database changes, another Patch would need to be created to restore the database objects back to their original state.
Reasons to consider using a Version upgrade:
Reasons to consider using a Patch upgrade:
Note: Patch install and uninstall use the logic in the Version install. Thus, new features for a Patch added in a LANSA release may require a new Version to be deployed before you can use the new LANSA features to patch your application.
This also means that patching Versions created with a previous version of LANSA may not work correctly as the Patch code may not be compatible with the Version code. It is therefore highly recommended to NOT upgrade the LANSA configuration which built the Version. What you need to do is to retain a separate Build Configuration for each Version of LANSA which you need to support in the field.
If your application will retain users on both LANSA Version 13.0 and 13.1 for example, you will need to retain a Configuration for both 13.0 and 13.1. Of course, you can insist that all users upgrade to the latest Version of your application if they want to receive updates so you only need to maintain the one Build Configuration.
