Page History

...

FrameworX 10.1 Update 5f, September 9, 2026

...

Alarms, Historian and redundancy

...

• Historian data keeps replicating to the standby on a redundant pair whose history database is very large and uses TimescaleDB compression. Rows still waiting to be replicated when their portion of the database was compressed could no longer be read, so each cycle read the whole table, exceeded the connection time limit, and restarted without draining the backlog. Alarm replication was unaffected, because alarm rows are replicated before compression takes place.
• A batch carrying a few unresolvable rows no longer stops Tag Historian replication in normalized configuration. The standby imports the rows it can resolve and reports the ones it cannot, and the active server records which tag index it could not map.
• The active server's runtime process stays bounded under alarm-history load on a redundant pair. A TServer.json key, Alarm.HistoryQueryMaxRows (default 100000), sets a server-side ceiling on how many alarm-history rows a single query may load. A query above the ceiling succeeds and returns the newest rows up to it, with a warning naming the requested count, the applied ceiling, and the configuration key.
• Redundancy settings are applied when the runtime auto-starts as a Windows service after a computer restart. The runtime reads the machine's network addresses correctly during early Windows startup, and any remaining network-timing condition is reported in the Windows Event Log instead of being silently ignored. A new optional /redundancywaittimeout:<seconds> TStartup argument waits for the network stack on machines where the network comes up slowly (default: no wait).
• Documented safe automatic-failback practices and /TimeAutoSwitch tuning. Automatic failback to the original primary does not pull back data the secondary accumulated while the primary was down; only a manual SwitchToStandBy triggers that reconciliation.
• Alarm history queries complete without a database syntax error on alarm historians reached through the native PostgreSQL, Oracle, and MySQL connectors. Where the query was rejected, the chart kept drawing the data it already held, so the failure was easy to miss, but the alarm markers were missing or out of date and the query failed again on every refresh. The correction covers the Trend Chart, the Drilling Chart, and the Alarm Viewer in both Alarm History and Audit Trail modes, in the rich client and the HTML5 client. Known limitation on alarm historians reached through an ODBC or OleDb connection, described below.
• See Breaking Changes and Deprecations below for the withdrawal of the handover replication drain barrier.

...

• OpenID Connect sign in works in solutions running on .NET Framework 4.8. Sign in previously worked only in multi-platform solutions.
• A logon is refused when the server’s user check fails internally. A failure part-way through the check was previously reported as a successful check and the client was allowed to connect. The refusal is reported to the client and recorded in the audit trail when remote-connection auditing is enabled. A normal logon is unaffected, and a wrong user name or password still returns the same specific reason as before.
• Stored credential values can no longer be read or overwritten by the AI tools through the Designer grid cell edit action, meaning passwords, API keys, tokens, and database logon passwords. Reading a protected column is refused instead of returning the stored value, and writing one is refused outright. Credentials continue to be set through the Designer security screens as before, and ordinary non-credential grid cells are unaffected.
• A security guard built on a parameterized display disables as configured. See Displays and Symbols above.

Upgrading from Update 5e

...

• .

...

Breaking Changes and Deprecations

...