{"id":3196,"date":"2026-04-20T14:30:33","date_gmt":"2026-04-20T06:30:33","guid":{"rendered":"https:\/\/www.dpriver.com\/blog\/?p=3196"},"modified":"2026-04-21T12:32:57","modified_gmt":"2026-04-21T04:32:57","slug":"datahub-15327-why-power-bi-m-language-queries-produce-zero-lineage-4-query-deep","status":"publish","type":"post","link":"https:\/\/www.dpriver.com\/blog\/2026\/04\/datahub-15327-why-power-bi-m-language-queries-produce-zero-lineage-4-query-deep\/","title":{"rendered":"DataHub #15327: Why Power BI M-Language Queries Produce Zero Lineage \u2014 4-Query Deep Analysis"},"content":{"rendered":"

DataHub issue #15327<\/a> reports a common Power BI + DataHub problem: four Snowflake-connected Power BI datasets produce zero upstream lineage<\/strong>. No tables. No columns. The lineage graph just stops at the Power BI boundary.<\/p>\n

We analyzed all four M-language queries from the issue, identified two distinct failure patterns, and ran real lineage extraction against each one using GSP’s Power Query M-language parser. Here’s what we found \u2014 and how we solve both patterns.<\/p>\n

Why DataHub Can’t Parse These Queries<\/h2>\n

The root cause is that Power BI doesn’t generate SQL \u2014 it generates M-language<\/strong> (Power Query Formula Language). M is a fully functional language (closer to F# than SQL) that Power BI uses behind the scenes for all “Get Data” and “Transform Data” operations.<\/p>\n

DataHub’s ingestion pipeline expects SQL. When it receives M-language, no SQL parser (sqlglot, sqllineage, or any other) can extract lineage from it because it’s not SQL<\/em>.<\/p>\n

Two Patterns, Both Solved<\/h2>\n

The four queries in #15327 fall into two fundamentally different categories. GSP’s Power Query M-language extractor (dbvpowerquery<\/code>) handles both:<\/p>\n\n\n\n\n\n\n
Pattern<\/th>\nQueries<\/th>\nWhat Happens<\/th>\nGSP Result<\/th>\n<\/tr>\n<\/thead>\n
Pattern A<\/strong> \u2014 M Navigation<\/td>\nQ1, Q3<\/td>\nTable reference encoded in M’s record-access syntax: {[Name=\"X\", Kind=\"Database\"]}[Data]<\/code>. No SQL anywhere.<\/td>\nTable-level lineage recovered<\/strong> via navigation chain parsing<\/td>\n<\/tr>\n
Pattern B<\/strong> \u2014 Value.NativeQuery()<\/td>\nQ2, Q4<\/td>\nM wraps actual SQL inside a Value.NativeQuery()<\/code> call. SQL has M-encoded escapes (#(lf)<\/code>, \"\"<\/code>).<\/td>\nColumn-level lineage recovered<\/strong> via SQL extraction + parsing<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Pattern A: Pure M Navigation (Queries 1 & 3)<\/h2>\n

These queries use M-language’s navigation syntax to reach Snowflake objects \u2014 no SQL at all. GSP’s M-language parser walks the navigation chain {[Name=\"X\", Kind=\"Y\"]}[Data]<\/code> to extract the full database.schema.table<\/code> path.<\/p>\n

Query 1: Navigation to a Snowflake View<\/h3>\n

Original M-Language:<\/strong><\/p>\n

let\n    Source = Snowflake.Databases(SnowFlakeConnector, SnowflakeWarehouse),\n    my_Database = Source{[Name=\"PROD201_DB_redacted\", Kind=\"Database\"]}[Data],\n    CONSUMPTION_Schema = my_Database{[Name=\"CONSUMPTION\", Kind=\"Schema\"]}[Data],\n    Details_View = CONSUMPTION_Schema{[Name=\"details\", Kind=\"View\"]}[Data],\n    #\"Changed Type1\" = Table.TransformColumnTypes(Details_View, ...),\n    #\"Filtered Rows\" = Table.SelectRows(#\"Changed Type1\", ...)\nin #\"Filtered Rows\"<\/code><\/pre>\n
GSP analysis:<\/strong> The parser identifies Snowflake.Databases<\/code> as the connector, then walks the navigation chain through three steps:<\/p>\n