Starting December 3, join live sessions with database experts and the Microsoft product team to learn just how easy it is to get started
Learn moreGet certified in Microsoft Fabric—for free! For a limited time, get a free DP-600 exam voucher to use by the end of 2024. Register now
In Power Query in Excel, we do a LeftAnti join to filter a table. Then we remove the join column because we don't need it, we just needed the LeftAnti join to filter the table. This worked fine until recently, and now when we run the query, the anti join does not run and we get all the rows in the table. If we get rid of the Remove Columns step, it works properly, so I suspect Query Optimization is breaking this. I think Excel just updated to Version 2403 (Build 17425.20236 Click-to-Run) 64-bit, so I'll bet something changed in that version for Query Optimization. If we view the steps in Power Query, the Merged Queries step shows an empty table, then all the rows show after the Removed Columns step. I would consider this a bug because the whole point of a LeftAnti join is to filter a table. By defintion, the column we are removing only has null records, so there is never a reason to keep this column.
As a work around, we have switched to a left join, expanded the result, and then filter on nulls to do the same as a LeftAnti join. But again, this defeats the whole point of having a LeftAnti option if we have to do this.
let
Source = #"Accounts in Output",
#"Merged Queries" = Table.NestedJoin(Source, {"L_C", "A_N"}, #"Accounts", {"L", "A"}, "Accounts", JoinKind.LeftAnti),
#"Removed Columns" = Table.RemoveColumns(#"Merged Queries",{"Accounts"}),
#"Added Custom" = Table.AddColumn(#"Removed Columns", "Last Refreshed", each LastRefreshedAt, type text)
in
#"Added Custom"
What's the original source for the data? And is it possible that the outcome is dependent on the case-sensitivity of the columns being joined?
There are no issues with case. All the data is uppercase.
The #"Accounts" query (right side of the AntiJoin) pulls from Excel.CurrentWorkbook().
#"Accounts in Output" (left side of the AntiJoin) is a query that has another query in the Source step that pulls from yet another query in the Source step, maybe 4 or 5 levels deep. The original source way back through the layers is an Oracle database using SQL, but there are a lot of merges and other transformation before it gets to #"Accounts in Output".
I tried reproducing the issue with hard-coded tables and it works fine, and in a simplified example pulling from Oracle, it works too. Maybe it's the multiple layers of queries? Any suggestions on how I can create a minimal reproducible sample or some trace that could show the issue?
Starting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early Bird pricing ends December 9th.
User | Count |
---|---|
35 | |
16 | |
12 | |
11 | |
9 |
User | Count |
---|---|
45 | |
27 | |
16 | |
14 | |
14 |