Update Manager

<< Click to Display Table of Contents >>

Navigation:  Reference Section > Installation and Deployment > License GUI >

Update Manager

The Update Manager (PC4UpdateGUI.exe) is the dedicated front end for updating a PrimeCut 4 server installation. It downloads an update, shows what is currently installed, migrates the datastore databases, and can roll the whole lot back again.

Open it from the License Server Manager via Updates > Open Update Manager.... It always runs elevated, because it stops and starts services and writes into the installation folder.

If an update is already running when you start the Update Manager, it warns you rather than letting two updates fight over the same files.

 

PC4 Installation Path

The Update Manager discovers the installation for itself and reports what it found for License Server, PrimeCut4 and Update Tool. Use Browse... if you need to point it somewhere else.

Setting the PC4_INSTALL_PATH environment variable overrides path discovery altogether, which is useful on machines with more than one installation.

 

Downloading an update

Two sources are offered:

Software Update Server - Check for Update asks the update server what is available, then Download Update fetches it with a live progress bar.

OneDrive Download - paste an anonymous OneDrive or SharePoint sharing link (either a file share or a folder share) and press Download from OneDrive. The link is redeemed and the file fetched through the site download endpoint.

Downloads are saved to your Downloads folder, and the Update Manager checks that what arrived really is a ZIP or an executable - so a sharing link that has expired or needs a sign-in fails visibly instead of quietly saving an error page.

Use Extract to Update Folder to unpack a downloaded ZIP ready for use.

 

Installed Versions

The Installed Versions panel lists License Server, Stp Service and Primecut side by side, showing the Installed version against what is in the Update Folder and in the Zip. That lets you confirm you are about to install what you think you are before anything is stopped.

 

Choosing the datastores

The datastore list shows Name, Path, DB Version, Status, Updatable and Last Backup.

Database versions and online status are read live from the local License Server, falling back to DataStores.xml when the server is not running. While the License Server is in the middle of stopping, Status shows - rather than a misleading value. Disabled datastores are hidden.

Update All and selecting a single datastore are mutually exclusive - you either do the lot or you pick one. After a successful update the list refreshes to the new versions and keeps your selection.

 

Version targets

Software Version and DB Version are chosen separately, so the application and the database schema can be moved independently.

DB Version is capped at, and defaults to, the schema version the installed update tool can actually provide - you cannot ask for a schema the tool does not know how to build.

Reapply Schema re-runs the latest migration, for when a migration needs to be applied again rather than moved forward.

Skip backup is only offered when a migration will actually run. If nothing is going to change the database there is no backup to skip.

Skipping the backup means there is no automatic way back if a migration goes wrong. Only skip it when you have taken a backup by other means.

 

Running the update

Test Update performs a dry run and Apply Update does the real thing. Both drive the server updater inline and stream its output straight into the embedded Output Log, so there is no separate console window to lose behind other windows.

The Progress tree builds itself as the update runs, one entry per step, marked as it completes:

ticked - the step succeeded

grey - the step was skipped

bold red - the step failed

Clicking a step in the Progress tree jumps the Output Log to that section, which is much quicker than scrolling a long log looking for the failure. Load Last Log replays a previous run so you can go back over an update after the fact.

 

Rolling back

Before an update replaces anything, the previous executables, plugins and key services are kept in a versioned subfolder of the PreviousVersion folder. A rollback works that out for itself: it detects the target version from what is stored there and asks you to confirm before it does anything.

Rollback also sets latestclientversion back, so clients do not start warning that they are out of date against a version that has just been withdrawn. If the database schema version is unchanged, the database part of the rollback is skipped.

Each rollback option shows the component versions it would restore, so you can see what you are going back to.

 

See also License Server Manager and Reduce Database.