Description

Steps to reproduce

1. Select a table in the tree (e.g. my_translations), so the "Table: …" editor tab is populated.
2. Switch to a Query tab and run
   ALTER TABLE my_translations ADD mapid INT UNSIGNED NULL, ADD boxid INT UNSIGNED NULL;
   – succeeds, server confirms.
3. Click on the "Table: my_translations" tab.

Expected

The column list shows the new columns mapid and boxid (or the tab reloads the structure when it is activated).

Actual

The tab still shows the old structure without the new columns. Nothing indicates that it is stale. Only after pressing F5 does the new structure appear.

Also affected: Data tab

With the structure still stale, pressing F5 on the "Data" tab re-runs the SELECT but builds the column list from the cached structure – the new columns mapid and boxid do not appear in the grid either. So even an explicit refresh on the Data tab does not pick up the altered structure. Expected: F5 on the Data tab reloads the table structure first and then selects all current columns.

Why this matters

There is no hint that the displayed structure is cached. I assumed the ALTER had not been applied, ran it again and got "Duplicate column name" from the server – that was the only way to notice the tab was outdated. Worse cases are easy to imagine: adding a column again with IF NOT EXISTS, or dropping/renaming the "missing" column based on what the tab shows.

Suggestion

Either:

• after a successful DDL statement (ALTER/CREATE/DROP/RENAME TABLE) executed in a Query tab, invalidate the cached structure of the affected table so the Table tab reloads on next activation, or
• reload the structure whenever the "Table: …" tab is (re)activated, or at least
• show a "structure may be outdated – press F5" hint on the tab when DDL has been run in the meantime.

Version

HeidiSQL: [your version]
Server: MySQL [your version]
OS: Windows [10/11]

HeidiSQL version and OS

[your version, e.g. 12.11] Windows 10

Database server version

MySQL 8.0.42

Reproduction recipe

1. Select a table in the tree (e.g. my_translations), so the "Table: …" editor tab is populated.
2. Switch to a Query tab and run
   ALTER TABLE my_translations ADD mapid INT UNSIGNED NULL, ADD boxid INT UNSIGNED NULL;
   – succeeds, server confirms.
3. Click on the "Table: my_translations" tab.
4. Switch to the "Data" tab and press F5.

Expected
Step 3: the column list shows the new columns mapid and boxid (or the tab reloads the structure when activated).
Step 4: F5 on the Data tab reloads the table structure first and then selects all current columns, so mapid and boxid appear in the grid.

Actual
Step 3: the Table tab still shows the old structure without the new columns. Nothing indicates that it is stale.
Step 4: F5 on the Data tab re-runs the SELECT but builds the column list from the cached structure – the new columns do not appear in the grid either. So even an explicit refresh on the Data tab does not pick up the altered structure.
Only after pressing F5 on the Table tab does the new structure appear everywhere.

Why this matters
There is no hint that the displayed structure is cached. I assumed the ALTER had not been applied, ran it again and got "Duplicate column name" from the server – that was the only way to notice. Worse cases are easy to imagine: dropping or renaming a column based on what the Table tab shows.

Suggestion

• After a successful DDL statement (ALTER/CREATE/DROP/RENAME TABLE) executed in a Query tab, invalidate the cached structure of the affected table so Table and Data tab reload it on next activation / F5, or
• reload the structure whenever the "Table: …" tab is activated, or at least
• show a "structure may be outdated – press F5" hint on the tab when DDL has been run in the meantime.

Error/Backtrace