Forum Discussion
Fabric Warehouse Incorrect Query Results
yeah, best to raise a ticket with product support - use the menu above Support > Product Support to log the new support case. Please make it clear in the ticket that removing the variable StartingDate resolves it; and the issue seems to be happening quite recently.
If my workaround helped please mark it as a solution, so that others in this situation can take advantage of this workaround!
Hi mheggie,
Before concluding it an engine bug or caching issue, I would like to first think purely from a data/query perspective. If you are only looking at row counts as validation, it is possible that even if there are only 67 distinct liability keys, [GL Account Key] in rpt.vw_DimGLAccount may contain 2,365 rows matching these 67 keys (given, no DISTINCT is being applied in the outer query).
Another reason could be that [LiabilityGLAccountKey] and [ExpenseGLAccountKey] contain identical values, or one is a subset of other, over the filtered date range.
Could you first verify this, by looking at the actual result sets, rather than relying solely on row counts?
Thanks for the feedback. I have evaluated the results along with the counts. What I've shared in my post is accurate. I should get 2365 rows returned for one query and 67 for the other. LiabilityGLAccountKey and ExpenseGLAccountKey values are not identical and are not a subset of one another. Liabilities post to a different place in the GL than expenses.
If I change the "select *" in each query to a "select count(*)", the numbers returned are correct. When I then change the "count(*)" back to "*", it returns the same result for both.
Also ... the process with this logic has been running successfully in production since May 2025. It is only in the last few weeks that this has been a problem. I've tested this with other keys that reference the same dimension and can consistently re-create the issue.
When the second query runs, it notes that it is using cached results.
