Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.
I keep having an issue whereby I need to access a column in a measure. So for example, I have data grouped by date, and then grouped by ID, and then further grouped by Type.
I have encountered an issue many times where I need, for example, in the creation of a measure, I need to access the date part, as well as the ID, but can't because they're part of the row context, and then I use a workaround that I'm not sure makes much sense (such as using the average date).
The way I think about it is that for each grouping, ie a particular date, and a particular ID, there is an associated date (as this is the way it is grouped) that is part of every row of that group, and I keep thinking it should be easy to access it and use, but can't seem to be able to.
Where am I going wrong?
Solved! Go to Solution.
You might be going wrong in how you think about Columns and Measures. Measures aren't written to consider each "cell" individually. If you need to make row by row calculations, thats what Columns are meant for, however they only calculate once during the data load. Instead Measures take in a context that can change, and give a result based on the group of data as a complete whole.
Now of course, in your design, you might know of certain logic constants. For example, if you know you are doing some form of context filtering which will only ever give you a single date in your range, you might include a statement like "FIRSTDATE('Table'[Column]) because you know you'll get the correct answer every time.
You might be going wrong in how you think about Columns and Measures. Measures aren't written to consider each "cell" individually. If you need to make row by row calculations, thats what Columns are meant for, however they only calculate once during the data load. Instead Measures take in a context that can change, and give a result based on the group of data as a complete whole.
Now of course, in your design, you might know of certain logic constants. For example, if you know you are doing some form of context filtering which will only ever give you a single date in your range, you might include a statement like "FIRSTDATE('Table'[Column]) because you know you'll get the correct answer every time.
Thanks for this. I guess I should also try to just play around compare the expected behaviour with what DAX is actually doing.
Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City
Check out the April 2024 Power BI update to learn about new features.
User | Count |
---|---|
118 | |
104 | |
77 | |
73 | |
52 |
User | Count |
---|---|
145 | |
109 | |
109 | |
90 | |
64 |