Microsoft Fabric Community Conference 2025, March 31 - April 2, Las Vegas, Nevada. Use code MSCUST for a $150 discount.
Register nowI 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.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!
Check out the February 2025 Power BI update to learn about new features.
If you love stickers, then you will definitely want to check out our Community Sticker Challenge!
User | Count |
---|---|
98 | |
69 | |
66 | |
49 | |
41 |