Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

The Fabric Community site will be in read-only mode on Monday, Feb 24 from 12:01 AM to 8 AM PST for scheduled upgrades.

Reply
Topographical
Frequent Visitor

A Conceptual Issue I keep having

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?

1 ACCEPTED SOLUTION
Anonymous
Not applicable

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. 

View solution in original post

2 REPLIES 2
Anonymous
Not applicable

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. 

Helpful resources

Announcements
Las Vegas 2025

Join us at the Microsoft Fabric Community Conference

March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!

FebPBI_Carousel

Power BI Monthly Update - February 2025

Check out the February 2025 Power BI update to learn about new features.

Feb2025 Sticker Challenge

Join our Community Sticker Challenge 2025

If you love stickers, then you will definitely want to check out our Community Sticker Challenge!

Feb2025 NL Carousel

Fabric Community Update - February 2025

Find out what's new and trending in the Fabric community.