SQL export: invalid views lead to orphaned placeholder tables (export should fail early or clean up

HeidiSQL version 12.15.1.1 (Windows, released 30 Jan 2026) ([heidisql.com][2])

DB server MariaDB (also reproducible with other server versions; server-version independent)

Description When exporting a database schema including views, HeidiSQL generates a workaround script that first creates placeholder tables with the same names as the views, and later drops them and recreates the real views. This is understandable and intentional to avoid dependency/order issues. ([heidisql.com][3])

However, if a view is already invalid (e.g., it references a table/column that no longer exists), the exported CREATE VIEW statement is invalid and fails during import/execution. At that point, the script has already executed many earlier statements, including the placeholder CREATE TABLE statements for views. Execution then aborts on the broken CREATE VIEW, leaving behind empty placeholder tables for (some) views. This makes the target schema incorrect and requires manual cleanup.

Steps to reproduce

1. Create a view that becomes invalid (e.g., create view referencing a table/column; then drop that table/column).
2. In HeidiSQL: export database as SQL with schema (tables + views).
3. Execute the export script on an empty target database.
4. Script aborts at the invalid CREATE VIEW. Placeholder tables created for views before that point remain as empty tables.

Current behavior

• Export script contains placeholder CREATE TABLE for views and later CREATE VIEW.
• If any view is invalid, executing the script aborts on the invalid CREATE VIEW.
• Placeholder tables for views remain in the target DB as empty tables, i.e. broken/dirty state.

Expected behavior

• Export should fail early (before producing a script that can leave the target in a wrong state) when at least one view is invalid. or, at minimum
• Export script should be self-cleaning/robust: if CREATE VIEW fails, no placeholder tables for views should be left behind (e.g., ensure cleanup of placeholders even on failure).

Rationale If the source already contains invalid views, an “export schema” operation should not generate a script that predictably leaves the target in a partially-applied and misleading state (tables where views should be). The root problem is the invalid view; leaving placeholder tables does not help and creates additional manual work.

How would you check whether a view is invalid, before its dependencies are resolved?