hMailServer 6.2.26
hMailServer 6.2.26
The release to take if you run the built-in SQL Server Compact database: the 6.2.25 installer reported every upgrade of one as failed, after the upgrade had in fact succeeded, and the check that gave the false verdict took the service down with it (#114). Nothing else in the server changes; the 6.2.25 notes still describe everything it does.
The fix
Every SQL Server Compact upgrade through schema 6030 was reported as failed after it had succeeded (#114). After each upgrade script, the database updater proves the schema changed by running a probe statement, and reads a failed probe as a missing object. The four probes for schema 6030, the foreign keys, were written with case when exists (subquery) in the SET expression - valid on SQL Server, MySQL and PostgreSQL, and on SQL Server Compact an access violation inside the OLE DB provider, on a correct database with every constraint present. The server caught the fault and reported it as HM10045 Unknown error, the updater declared that Upgrade6029to6030MSSQLCE.sql had not created fk_hm_accounts_domain and blamed an [IGNORE-ERRORS] marker the statement does not carry, and the installer said the database could not be upgraded. Two seconds after answering the probe, the server's crash oracle - which treats a memory-safety fault as fatal - ended the service, and service recovery started it again.
Reproduced from a Compact Edition database created at schema 6011 and upgraded with the shipped scripts: it reaches 6030 with all seventeen foreign keys, and the probe then faults the provider. The probes now read update hm_dbversion set value = value / (value - value) where not exists (select 1 from information_schema.table_constraints where constraint_name = '...' and constraint_type = 'FOREIGN KEY'): with the constraint present no row matches and nothing is evaluated; with it absent the one row matches and the division by zero fails the statement on every backend, leaving hm_dbversion untouched. The updater's message no longer asserts a cause it cannot see; it gives the backend's own words and says how to read them.
So that a probe the backend cannot run is caught before a release: build/check-db-scripts.ps1 now executes every probe against the database it builds from the create script, through the provider the server uses, with a negative control that must fail; and a regression fixture runs them through the same COM path the updater takes, against the bench database, which is Compact Edition. Both fail on the 6.2.25 statement.
If the 6.2.25 installer failed on your database, it is at schema 6030 with its foreign keys in place, and this installer finds nothing left to upgrade. If you restored a backup from before, the whole chain runs and the verification passes.
Also in it
- Two roadmap rows closed on what 6.2.25 did (the fuzz run and the assertion-build gate a release records, and the accessibility audit), and the native-coverage rows now say why they are blocked rather than merely open.
Upgrading
From 6.2.25: run the installer. From 6.2.24 or earlier: the 6.2.25 notes and, before them, the 6.2.24 notes describe what changes on the way; everything there still applies.
Verification
Two clean Release builds of the stamped tree produced the same hMailServer.exe byte for byte (SHA-256 89E72B5B143FD0B9AFD20A4A7848AB1F746E58582BF015238147B74F352A5329); the full regression suite ran on the assertion build (every HM_ASSERT live: 2004 tests, 1997 passed, 0 failed, the 7 explicit skips, no assertion violated) and again on the shipping binary (2004, 1997 passed, 0 failed, 7 skipped), with the three new probe tests in both runs; the Control Panel's own tests passed; the database checks ran all 64 schema probes against a freshly created database with the negative control failing as it must. Installer hMailServer-6.2.26-x64.exe SHA-256 BFB1E5D606D3FB18B2BBBE26A8704A29033C807E293988265F47E75891905F1E; the SBOM and the cosign signatures attached to this release were produced and verified by the workflows after the tag.