Troubleshooting

Troubleshooting: generated SQL fails on the target database

Use this page when you run a script Kenseme generated and the database rejects it. For how generation works, see the SQL generation overview.

Syntax errors or unrecognized statements

Likely cause: The version’s dialect doesn’t match the database you ran it on, or a view or procedure body was written for another dialect.

Resolution:

  1. Check the Dialect: badge in the generate dialog. A version keeps the dialect the schema had when it was created.
  2. If it’s wrong, change Default Database Dialect on the schema’s Settings tab and create a new version.
  3. If the failing statement is inside your own view, procedure, or function, fix that dialect’s script on the object’s SQL tab. Kenseme emits those bodies as written.

An object is missing from the database

Likely cause: The object had no script in the version’s dialect, so it was skipped. Or the table had no columns.

Resolution: Look at the warnings the generate dialog showed before you clicked Generate, or at Dialect limitations in a migration result. Add the missing dialect script or columns, create a new version, and generate again.

“Object already exists”

Likely cause: A migration script ran twice without guards, or a view or procedure body has no guard of its own.

Resolution:

  • Generate migration scripts with Use idempotent guards (IF EXISTS / IF NOT EXISTS) on (the default).
  • Version scripts already use existence checks for schemas, tables, and indexes. For your own views and procedures, write them with CREATE OR ALTER or CREATE OR REPLACE where the dialect allows.

A foreign key fails to create

Likely cause: The referenced table doesn’t exist yet, or the target doesn’t support the constraint.

Resolution:

  • Run the full script, not individual statements, so tables are created before their keys.
  • For Fabric Lakehouse, foreign keys are never emitted. If you see one, it is inside your own SQL.
  • To create tables without foreign keys, leave Include Foreign Key Constraints unticked on version scripts (it is off by default) or untick it on migration scripts.

Defaults are missing or rejected

Likely cause: The target doesn’t support column defaults as written.

Resolution:

  • Fabric Warehouse doesn’t support column defaults, so Kenseme leaves them out. Supply the values in your inserts.
  • Fabric Lakehouse needs the Delta allowColumnDefaults feature. Kenseme adds it to any table with a default. If the error persists, check that your runtime supports Delta column defaults.

Duplicate keys in Fabric Warehouse

Likely cause: Fabric Warehouse primary keys are NOT ENFORCED. The engine accepts duplicate keys.

Resolution: Enforce uniqueness in your load logic. Pipeline load strategies that merge on business keys do this for you.

“Permission denied”

Likely cause: The account running the script can’t create objects in the target.

Resolution:

  1. Check the account can create schemas, tables, views, and procedures in the target database.
  2. For Snowflake and Databricks, check the role’s grants on the database or catalog and the schema.
  3. The script also creates the z_blaze_version table. The account needs permission for that too.

“Object not found” when a procedure runs

Likely cause: A load procedure reads from a source schema that is named differently in this environment, or isn’t reachable.

Resolution:

  1. Regenerate the script with the right target in the Environment section, so Kenseme fills in that environment’s schema names.
  2. Check the source schema exists and the running account can read it.
  3. For cross-database reads, check the three-part names (or linked server) resolve in the target.

The script ran, but no rows were loaded

Likely cause: Run-time values don’t match the data, for example a watermark or batch value.

Resolution: Check the load strategy’s parameters, confirm the source has rows for the values you passed, and read the procedure’s job log if the Pipeline has one. See Pipeline load strategies.