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

Grow your Fabric skills and prepare for the DP-600 certification exam by completing the latest Microsoft Fabric 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
RTI Forums Carousel3

New forum boards available in Real-Time Intelligence.

Ask questions in Eventhouse and KQL, Eventstream, and Reflex.

MayPowerBICarousel1

Power BI Monthly Update - May 2024

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