Update Reportworq#

Settings > Update Reportworq is the in-product way to keep an instance current. It lists available software versions and updates the instance to the latest official release, the latest hotfix, a specific version, or from a patch file. Update actions download and install builds and restart the service, so they are administrator-only and should run in a maintenance window.

Before you begin#

• System-administrator rights.
• A maintenance window, updates restart the service and interrupt active reporting.
• For online methods, connectivity to the update source. For an isolated server, a patch file provided out of band.
• A backup, see below.

Back up before you update#

1. Create a timestamped backup from Settings > Configuration > Web Server > Backup, then select Create backup. Reportworq writes a dated archive (for example reportworq_data_backup_2024-10-05 20.41.38.zip).
2. Note the Bootstrap Service startup type and logon account.

Modern upgrades also auto-back-up the Repository before applying. Keep the pre-upgrade backup: occasionally an upgrade introduces non-backward-compatible database changes, so downgrading past such a build is unsafe.

If you need to downgrade, or a downgrade does not behave as expected, contact Reportworq support before going further. Reversing a version that changed the Repository is not a self-service operation, and support can tell you whether the build you are on is one of the affected ones.

Restore from a backup#

Reportworq has no in-product restore button; a restore is a manual file operation. Do it with the service stopped so no process holds the Repository open, the same discipline used when moving servers.

1. Stop the Reportworq 6 Bootstrap Service on the server (services.msc).
2. Extract the backup archive's contents into the Repository folder, replacing the current contents.
3. Start the Bootstrap Service.
4. Sign in and confirm jobs, schedules, and datasource connections are intact.

Update Reportworq#

1. Open Settings > Update Reportworq. The versions grid loads in the background; use Refresh if it is empty or slow.
2. To see hotfix builds, turn on Show Hotfix Versions. A hotfix is a fully tested update to the current official version that contains only critical fixes, no new features and no experimental changes. Hotfixes are hidden by default and applied on support's guidance.
3. Open the Update menu and choose a method:
   • Update to latest official version, installs the newest official release.
   • Update to latest hotfix version, installs the newest hotfix build (shown only when hotfixes are visible).
   • Download a specific version, targets a chosen version from the grid.
4. The update installs and restarts the service. Confirm the new version on the Settings landing card afterward.

Update an air-gapped instance#

When the server cannot reach the update source, update from a patch file provided out of band.

1. On an internet-connected machine, download the patch file (Reportworq_Patch_<version>.zip, for example Reportworq_Patch_5.0.0.75.zip) for the target version.
2. Transfer it to the server.
3. In Settings > Update Reportworq, open the Update menu and choose Update from a patch file, then select the transferred file. The upload shows a progress indicator while it applies.
4. The update installs and restarts the service. Confirm the new version on the Settings landing card.

Update a container deployment (Docker or Azure App Service)#

A container deployment runs from a read-only image, so it does not update itself. The steps above do not apply, and the product will tell you so rather than letting you try.

On these deployments the Update Reportworq screen becomes informational:

• The Update menu and every per-row activate, remove, and download action are hidden.
• A callout reports the running version and how to change it.
• The version grid stays visible, read only, so you can still see what is running and what exists.

The update itself happens at the container host, not in Reportworq. Swap the container image tag, or the App Service container setting, to the version you want and restart. The new image is the update, and the Repository on its mounted storage carries your content across unchanged.

Update worker nodes the same way, and keep them on the same version as the web instance.

Why it works this way. A container's filesystem is meant to be disposable, so an in-app updater that rewrites the install directory and restarts a service would fight the platform. Reportworq detects the immutable deployment profile and steps aside. See Deployment topology.

Update a load-balanced cluster#

All servers in a cluster should run the same Reportworq version, so update them together in a maintenance window.

1. Update the main server first, using the steps above.
2. Update each load-balancer node to the same version.
3. Coordinate the node restarts so jobs are not dispatched to a node mid-update. On the Load Balancer screen, a node's Status reflects whether it dequeued a job in the last two minutes; let nodes settle before and after each update.

See Deployment topology for the cluster model.

Notes and limits#

• Update actions are disruptive (install plus restart) and should not run during active reporting.
• Software-version and restart events are recorded in the System audit log under the Informational category, see Audit logs.

Going deeper. The backup-and-restore-into-Repository discipline here is the same one used when moving servers, see Migrate to a new server.