SQL compatibility check

Fabric has several SQL engines, and they don't take the same SQL. The SQL query page checks what you write against the engine you pick, as you type, and lists what that engine doesn't support or may run differently. It is in preview.

The check is static: Fabric Desktop by KratosBI reads the SQL; it doesn't run it, doesn't connect to Fabric and uses no capacity. It never changes your SQL. Each finding says what to change, and you decide.

No findings means no known problem, not proof that the query runs, or gives the same answer, in Fabric. A query that runs on this PC with DuckDB says nothing about how a Fabric Warehouse runs it.

Pick the engine#

The dialect list next to Run is also the engine the SQL is checked against:

T-SQL is checked and formatted here but never run on this PC.

Findings#

Findings are underlined in the editor, marked in the gutter and listed in the Compatibility panel beside it. Hover an underline, or pick a finding in the panel, to see:

• the severity and rule ID (for example SYN-001);
• what's wrong and why, in the engine's terms;
• what to do instead;
• the target engine, line and column;
• the confidence (high, medium or low) and a Source link to the Microsoft or Apache page the rule comes from.

The panel shows the engine, the rule set's version, the number of statements, the count of each severity and an outcome: Known problems, Review the warnings, Not verified, or No known problems found by static checks. There is no percentage score: a count of rules passed says nothing about whether a query works.

When you run Spark SQL or DuckDB on this PC and the check found differences from Fabric, a note under the results says so. It never stops the run.

Queries over 100,000 characters are checked when you press Check now in the panel, so typing never waits on the engine; scripts over 500,000 characters aren't checked. The panel lists the first 1,000 findings; the counts include all of them.

Export#

Export JSON saves the report to your Downloads folder as <query name> compatibility <engine> <date time>.json. It never replaces a file: a name that's taken gets a number. The file holds the SQL that was checked and its SHA-256 hash, the engine, the rule set version, every finding with its fields, the counts and the outcome (schema: sql-compat-report@1). It holds the SQL, so treat it like the query itself.

What it doesn't do#

• Run the SQL, sign in, call Fabric or use capacity.
• Rewrite your SQL.
• Know your tables' column types, your warehouse's collation or your Fabric runtime version; findings that depend on them are warnings or unverified.
• Check every construct. Statements the engine treats as commands (GRANT, DBCC, SHOW, OPTIMIZE and similar) are checked only by the rules that read their words.
• Put SQL text or findings in the security audit log, or put string literals in findings: a password in the SQL never shows in a message.

Rules#

Rule set 2026.10.1, from Microsoft Learn and the Apache Spark 3.5 reference as they read on 2026-10-17. Each Microsoft page's "last updated" date is kept in sidecar/fabric_desktop/sqlcompat/profiles.py. DDL-007 (ALTER TABLE) is an error except ALTER COLUMN, which is a warning because it is in preview.

How it's built and tested#

• sidecar/fabric_desktop/sqlcompat/: profiles.py describes each engine (statement categories, unsupported types and their alternatives, identifiers, transactions, DDL and DML, semantic differences, confidence and sources); rules.py holds the rules, each naming its engines, severity, confidence and source; analyzer.py splits the SQL into statements (at ; and T-SQL's GO), reads each with sqlglot and the engine's tokenizer, applies the rules and builds the report. Rules work on tokens first, so they still find problems, at exact positions, in statements sqlglot can't read.
• The engine methods are sql_analyze, sql_compat_profiles and sql_compat_export.
• sidecar/tests/fixtures/sql_compat_v1.jsonl holds 192 cases: the SQL, the engine, the expected outcome, the exact set of rules expected and where the first finding is. 35 of them are false-positive guards, SQL that must not be flagged (Spark array indexes, ISNULL(a, b) in T-SQL, UPDATE ... SET x = NULL, keywords inside strings and comments, triggers in a SQL database). sidecar/tests/test_sql_compat.py runs them.
• Changing a rule means moving RULE_VERSION on, reviewing the fixtures and updating this page.