Release Notes — WUIC Framework v1.7.12

Date: 20 September 2026 Previously published version: 1.7.11 (20 September 2026) Backend: .NET 10 + IIS / Linux nginx Frontend: Angular 21

This version actually closes the reports that printed an empty page on MySQL and PostgreSQL. The two previous versions declared that defect fixed by correcting the query: the query was not the problem, and the report kept coming out with its header and not a single row. The real cause was found by comparing, on the same installation, a report shipped in the package and one built on the spot from that installation's own columns: both printed blank, so the problem was not in the report file.

📊 Reports print their data on MySQL and PostgreSQL

A Stimulsoft report keeps two distinct things in its dictionary: the connection to the database and the type of the data source. When a report was opened, the framework replaced the connection with the one of the engine in use — StiMySqlDatabase, StiPostgreSQLDatabase — but left the data source with the type it had been created with, StiSqlSource, which to Stimulsoft means SQL Server.

A SQL Server source sitting on a MySQL database raises no error: it simply returns an empty dataset. The report was drawn correctly — header, frame, "page 1 of 1" — and printed no row.

Converting the source to the engine's own type already existed in the product, but for Oracle only, in two separate places (the viewer and the designer). It now covers MySQL and PostgreSQL in both. If you have reports that printed blank, there is nothing to regenerate: just open them again.

🔑 Metadata indexes on MySQL

On MySQL installations created by the guided first start, the migration that creates the indexes on the metadata hot paths failed with Fatal error encountered during command execution.

The reason is in the connection string the wizard writes: without Allow User Variables=True the MySQL driver reads every @name in a script as a parameter instead of a server variable. The framework's normal queries do use parameters, so they worked; that migration uses server variables, and died. The key is now added to the metadata connection, both when the wizard composes it and when the backend rewrites it.

🧩 Dynamic query on PostgreSQL

The PostgreSQL gateway called the function that builds dynamic queries passing it 19 arguments, while the PostgreSQL satellite accepts 15: the call always failed with MissingMethodException. The arguments are now the right ones, and that gateway's error message also says how many arguments were passed and how many versions of the method exist — because "method not found", on its own, sends you looking for a method that is in fact there.

📦 Updated packages

🔧 Recommended operational updates

1. No configuration change required: the appsettings.json keys are unchanged.
2. If you have reports that printed blank on MySQL or PostgreSQL, open them again: there is nothing to regenerate.
3. On MySQL installations already in service, if you want the index migration to succeed, add Allow User Variables=True to MetaDataSQLConnection in appsettings.json. New installations get it from the guided first start. On MySQL the impact is limited: two of the three indexes are already covered by the route's unique constraint and by the index InnoDB creates on its own for foreign keys.