QuikData Database Upgrade Application

What the Upgrade Tool does

The QuikData Upgrade Tool updates the QuikData databases on your site to a newer version. In a single guided run it:

• Upgrades the DRControl, DRWorkflow, and all environment (project) databases, plus the optional QuikDataEnvTemplate / Model database if one exists on the SQL Server.
• Takes a verified backup of every database before it changes anything (recommended, on by default).
• Applies the update scripts supplied by QuikData, in order, to each database. Each script runs in its own transaction — if a script fails, that change is rolled back automatically.
• Verifies afterward that every environment database's structure matches the template (“schema parity check”) and lets you save a report of the whole run.

The tool updates databases only. It does not update the QuikData website (IIS) or the Worker services — those binaries are updated separately after the database upgrade completes.

Who should run it

A Site Administrator with access to the SQL Server. Specifically, you need:

• A login on the SQL Server with sysadmin rights (the tool must run BACKUP DATABASE, create the SchemaVersion tracking table, and make schema changes). Either a SQL login (username + password) or your Windows account can be used.
• Access to the machine where the tool runs, with network connectivity to the SQL Server.
• Coordination authority over the site — you will be taking QuikData offline for the duration of the upgrade.

Credentials are used only for the session; the tool does not store your password.

What you will need

Gather these before you start:

Upgrading across multiple versions? The tool applies one major version per run. To go from V57 to V59, run the tool once with the V58 script folder, then again with the V59 folder.

Before you run the upgrade

Complete these steps first — the tool does not do them for you:

1. Pause all QuikData Workers. No processing jobs (imports, indexing, productions, etc.) should be running or able to start during the upgrade.
2. Stop the QuikData website in IIS. No users should be connected while database changes are applied.
3. Confirm free disk space on the SQL Server for the backups (compressed backups are typically much smaller than the databases, but leave generous headroom).
4. Schedule a maintenance window. Backup plus upgrade time depends on database sizes; large sites should plan for several hours.

Restart IIS and the Workers only after the upgrade finishes successfully (see After the upgrade).

Running the upgrade, step by step

Launch QuikData.UpgradeTool and follow the wizard. Use Next to advance; nothing is changed in any database until the Confirm page tells you so.

1. Welcome

Summarizes what the tool will do. Click Next.

2. SQL admin login

• Enter the SQL Server name, and the DRControl and DRWorkflow database names.
• Enter your Login and Password, or check Use Windows authentication.
• Click Test connection. Wait for the green “Connected to server” message before continuing. If the test fails, see Troubleshooting.

3. Topology

The tool discovers every QuikData database on the server(s): DRControl, DRWorkflow, all environment databases, and the environment template.

• Confirm the DRWorkflow server is correct (click Re-discover if you change it).
• Review the discovered list. Every database that should be upgraded must be checked. Uncheck a database only if you have a specific reason to skip it — skipped databases end up on an older version than the rest of the site.

4. Sniff & Bootstrap

Each selected database is checked for a SchemaVersion tracking table. Databases that don't have one yet (first time using the tool) get a single baseline marker recording their current version — this is how the tool knows which scripts each database still needs.

• Confirm the Baseline version (the version your site is on now) and the Target version (the version you are upgrading to) match the script package QuikData sent you.
• For example a patch being applied to a 5.9 instance, you would put V59, V59

5. Backup (recommended)

• Leave Back up databases before upgrade (recommended) checked. The upgrade is forward-only — the tool has no undo. If a script fails partway through, these backups are your recovery path.
• Enter the Destination folder. This is a path on the SQL Server machine, not on the computer running the tool. SQL Server itself writes the backup files there.
• Click Start Backup and watch the per-database progress. Each backup is compressed, checksummed, and then verified with RESTORE VERIFYONLY.
• Backup files are named DatabaseName_YYYYMMDDTHHMMSSZ.bak.

This page also acquires the upgrade lock, which prevents two administrators from upgrading the same databases at once. If a lock message appears in red, see Troubleshooting.

Skipping backups: if you uncheck the backup option, the tool shows a warning — only proceed without backups if you have your own tested backup/restore strategy (for example, verified nightly backups taken immediately before the maintenance window).

6. Confirm

The last stop before changes are made.

• Point Scripts root folder at the version folder from QuikData (e.g. ...\Scripts\V59), then click Refresh preview.
• Review the summary (target version, database count, backup folder) and the per-database preview — it lists the exact scripts each database will receive.
• If any Optional one-shot migrations are listed, read their descriptions and tick the ones QuikData has instructed you to run. They are safe to re-run — work already done is skipped.
• Double-check the reminder at the bottom: IIS and Workers must already be stopped. Then click Next to start.

7. Execute

The upgrade runs. Per-database progress is shown at the top and a live log at the bottom.

• Do not close the window until the run finishes.
• If a script fails, only that database stops (the failed change is rolled back automatically); other databases continue. A Retry failed scripts button appears — see Troubleshooting before using it.
• Use Copy next to a failed row, or Copy log, to capture details for QuikData support.

8. Result

• A banner shows the outcome, with per-database results and counts of succeeded / failed / skipped.
• After a fully successful run, the schema parity check runs automatically, comparing each environment database against the template. All rows should read identical.
• Click Save report... and keep the report with your maintenance records.
• Click Finish.

After the upgrade

1. Confirm the Result page showed success for every database and the parity check found no differences.
2. Complete any remaining steps from QuikData for this release (for example, updating the website and Worker binaries).
3. Restart the QuikData website in IIS.
4. Resume the Workers.
5. Log in to QuikData and spot-check a project (open a room, run a search) before announcing the site is back.

Troubleshooting

The tool writes a detailed log on the machine where it runs:
C:\ProgramData\QuikData\UpgradeTool\logs\upgrade-YYYYMMDD.log
Include this file (and the saved report) whenever you contact QuikData support.

“Test connection” fails / cannot connect to the SQL Server

The message next to the Test connection button shows the underlying SQL error. Common causes:

“Upgrade already in progress” / lock message on the Backup page

The tool takes a per-database lock in DRControl so two people can't upgrade at once.

• Fresh lock (no Force unlock button): someone else is genuinely running an upgrade. Coordinate with them; only one upgrade can run at a time.
• Stale lock (Force unlock and retry button shown): a previous run was killed or crashed and left its lock behind (a lock is considered stale after about 5 minutes without a heartbeat). If you are certain no other upgrade is running, click Force unlock and retry.

Backup fails (“Cannot open backup device...”, “Operating system error 3/5”)

• Remember the destination folder is on the SQL Server machine. A path like D:\Backups means drive D of the SQL Server, and the folder must already exist there.
• The SQL Server service account (not your login) writes the file — it needs write permission on that folder.
• Operating system error 3 = path not found (folder doesn't exist on the server). Error 5 = access denied (grant the SQL Server service account write access).
• Check free disk space on the server drive.
• Hosted/managed SQL (for example Amazon RDS) does not allow native BACKUP DATABASE. On such sites, uncheck the backup option and use the platform's own snapshot/backup facility immediately before upgrading.

The Confirm page preview shows no scripts / wrong scripts

• Make sure Scripts root folder points at the version folder itself (the one containing DRControl, DRWorkflow, DREnvironment), not its parent and not one of the subfolders.
• Databases already at the target version correctly show no pending scripts.

A script fails during Execute

• The failed script's changes were rolled back automatically — that database is left at its last good state, with earlier successful scripts still applied and recorded.
• Click Copy on the failed row and save the live log, then contact QuikData support with both.
• If support identifies a transient cause (deadlock, timeout, out of disk space) and you have resolved it, click Retry failed scripts — already-completed scripts are skipped and the run resumes where it stopped.
• Do not restart IIS or the Workers while any database is failed or partially upgraded.

Parity check reports differences

The upgrade itself succeeded, but an environment database's structure differs from the template. Click Copy details on the affected row and send the diff to QuikData support before putting the site back online. After a fix, use Re-run parity check to confirm.

The tool closed or the machine rebooted mid-upgrade

Databases already completed are fine; the database being upgraded at that moment keeps all scripts that finished (each is recorded in SchemaVersion as it completes). Start the tool again with the same settings — it re-detects what each database still needs and you may need to use Force unlock and retry on the Backup page to clear the stale lock.