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

Earn a 50% discount on the DP-600 certification exam by completing the Fabric 30 Days to Learn It challenge.

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
LearnSurvey

Fabric certifications survey

Certification feedback opportunity for the community.

PBI_APRIL_CAROUSEL1

Power BI Monthly Update - April 2024

Check out the April 2024 Power BI update to learn about new features.

April Fabric Community Update

Fabric Community Update - April 2024

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