March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early bird discount ends December 31.
Register NowBe one of the first to start using Fabric Databases. View on-demand sessions with database experts and the Microsoft product team to learn just how easy it is to get started. Watch now
I have the following query for a calculated column, which uses variables set by filtering down tables to a single value. These two variables are then used in a two part conditional statement to set a string value. With the data that this is running against, the first condition should apply so that the statement returns the string "ha".
The observed behaviour is that when the output of the second condition is the string "Ha" then the first condition is ignored and the string "Ha" is returned. If however the output of the second condition is changed to "Hat" then the first condition is preferred and the value returned is "ha". No other changes are made in the system to affect this behaviour.
Initially I was using SUMMARIZE to pull the tables down to a single column and I thought this might be the problem. However, the behaviour persisted when I changed to using SELECTCOLUMNS. It doesn't seem to persist if I manually set the strings. Something strange is happening in the queries that set Condition1 & Condition2 but I can't figure out how or why changing the output values for the conditions should have any effect on the expressions that are evaluated in conditional statements, nor on the expressions that set the variables.
What is going on here? Is this a behaviour that is logical if seen through the right DAX lens or is it some kind of bug?
Re the effect of setting the variables using assigned strings I said:
"It doesn't seem to persist if I manually set the strings. Something strange is happening in the queries that set Condition1 & Condition2 but I can't figure out how or why changing the output values for the conditions should have any effect on the expressions that are evaluated in conditional statements, nor on the expressions that set the variables."
Thanks for your time and patience trying to explain this for me. At the end of the day I don't think the answer is needed in order for me to design a working solution but I just find it weird and weird bugs me.
I still am struggling to understand how equivalence in the output values (due to case insensitivity) can cause the nested condition to be evaluated before the condition that contains it. I'm also not sure why this behaviour would be seen when the variables Condition1 and Condition1 are set in the way shown but not when the variables are set by simple assignment of a value.
Regarding evaluation according to row, this behavious only bites on rows where the returned value should be set by the first conditional. All other rows in the table were returned correctly - following the logic in the second conditional.
You can't tell from the results which branch of the condition is being returned, because the text will be converted to the same case as the first row to be evaluated. For an example, create 2 tables like
Tmp 1 = { "Ha", "ha" }
Tmp 2 = { "ha", "Ha" }
Both rows of the tables will show the same values, with the case depending on which was evaluated first.
So why does this issue go away if I assign values to the variables rather than getting them from the two queries? If it was simply to do with the the first row on which the expression is evaluated, shouldn't that then carry through into the simpler situation where the variables are simply assigned?
From your original post it seemed that the behaviour only changed when you changed the strings which the condition returned ?
Values in DAX are case insensitive, so "Ha" = "ha". My guess is that the value shown for the column will depend on which row is evaluated first, so if the first row evaluates to "ha" then all the others will show as that. I am not sure, though, what order rows are evaluated in when it comes to calculated columns.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!
Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions.
Arun Ulag shares exciting details about the Microsoft Fabric Conference 2025, which will be held in Las Vegas, NV.
User | Count |
---|---|
25 | |
18 | |
15 | |
9 | |
8 |
User | Count |
---|---|
37 | |
32 | |
18 | |
16 | |
13 |