View Issue Details

IDProjectCategoryView StatusLast Update
0005837CaseTalk ModelerOtherpublic2026-07-30 13:54
ReporterMarco Wobben Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
Target Version15.0Fixed in Version15.0 
Summary0005837: No way to check whether a server database has all its columns
Description

Uploading a model to the server can fail with a message that a column does not exist, on a database that reports exactly the version CaseTalk expects.

There are two ways a database ends up in that state:

  • An upgrade did not run to the end. The stored version is raised by the last statement of an upgrade script, and SQL Server Management Studio carries on after a statement fails, so a step that broke halfway - or was cancelled, or only partly executed - still leaves the database reporting the new version while some of its columns were never added.

  • The database was installed fresh at a version whose install scripts did not yet contain columns that had only ever been added by an upgrade. Such a database never runs that upgrade, because the version it reports is already current.

An administrator has no way to tell whether a database has the complete layout, other than uploading a model and seeing whether it fails, and no way to close the gap other than comparing the database against the scripts by hand.

TagsNo tags attached.
CaseTalk EditionCorporate

Activities

Marco Wobben

Marco Wobben

2026-07-30 13:49

administrator   ~0008735

The script package that ships with CaseTalk Server (installed into the SCRIPTS folder) now carries two scripts that compare a database against the complete column layout of that same package:

Detect-SchemaErrors.sql - read-only. Reports every table or column that is missing, too narrow, of another type, or unexpected. It changes nothing, so it can be run at any time.

Repair-Schema.sql - adds the missing columns and widens the narrowed ones, then checks again and reports whatever it could not settle by itself. Columns that are unexpected, or that have a different type than expected, are deliberately left alone: those can hold data, so removing or converting them stays a decision for the administrator.

Both are safe to run more than once, and neither touches the stored database version - a repaired database keeps the version it had.

The installation instructions in the package have a new section describing when and how to run them, and both the fresh install and the upgrade procedure now end by pointing at it. Running the report is the only way to establish that a layout is complete; the stored version does not prove it. The upgrade procedure also warns to check for errors after every script, since a failed step does not stop the version from being raised.

Issue History

Date Modified Username Field Change
2026-07-30 13:47 Marco Wobben New Issue
2026-07-30 13:49 Marco Wobben Note Added: 0008735
2026-07-30 13:49 Marco Wobben Status new => resolved
2026-07-30 13:49 Marco Wobben Resolution open => fixed
2026-07-30 13:54 Marco Wobben Description Updated
2026-07-30 13:54 Marco Wobben Fixed in Version => 15.0
2026-07-30 13:54 Marco Wobben Target Version => 15.0