FAQ

FAQ: SQL generation and versions

Tip: For step-by-step instructions, start with the SQL generation overview.

Why can’t I generate a script from the live schema?

Whole-schema and migration scripts come from versions, so what you deploy always matches a snapshot you can open, compare, and roll back to. Create a version first, then use Generate Script on it. For one table, the table’s SQL tab works on the live definition. See Generate a script from a version.

What’s the difference between Full Script, Create Objects, and Load Script?

Full Script has everything. Create Objects has the tables and everything you wrote yourself. Load Script has only the Generated Objects that a Pipeline produced (load views, procedures, and scripts), and assumes the tables already exist. Run Create Objects first, then Load Script, when structure and load logic are deployed separately.

Why does the script target the wrong dialect?

A version keeps the dialect the schema had when the version was created. Change Default Database Dialect on the schema’s Settings tab, make sure your views and procedures have a script in that dialect, and create a new version.

Why is a view or procedure missing from my script?

It has no script in the version’s dialect. The generate dialog warns you about each one before you generate, and Create Version warns you too. Add the dialect on the object’s SQL tab with Add Dialect, then create a new version.

Why does Databricks or Fabric Lakehouse give me an .ipynb file?

Those platforms run PySpark rather than stored procedures, so whole-schema scripts are Jupyter notebooks with Spark SQL and Python load functions. Migration scripts are still .sql files. See PySpark notebooks.

What is the z_blaze_version table in my database?

Every version and migration script creates it (if needed) and adds a row with the version number, schema name, script type, and who generated the script. Query it to see which version a database is on. It is safe to keep.

Can I migrate between versions with different dialects?

No. Both versions must use the same dialect. To move a schema to another platform, duplicate it into the new dialect and generate a full script there. See Create a schema.

Are enum changes included in migration scripts?

No. When enums change between two versions, the migration dialog lists it under Dialect limitations. Review the changes on the comparison page and apply them by hand.

Should I turn on AI validation?

Turn it on for scripts you are about to run somewhere that matters. Validate script with AI agent sends the script to a reviewer that flags dialect problems and ordering issues. It counts toward your AI usage, so it is off by default.

What if validation flags an issue?

Fix the cause in Kenseme (a column type, an object name, a view body), create a new version, and generate again. If you edit the downloaded file instead, the next script you generate won’t include your fix.

Does rolling back a version change my database?

No. Rollback only changes the design in Kenseme. To take a database back, generate a DOWN migration between the two versions and run it. See Roll back to an earlier version.

Which dialects are supported?

SQL Server, PostgreSQL, MySQL, Redshift, Snowflake, Databricks, Fabric Warehouse, and Fabric Lakehouse. See Supported database targets.