The first example with dynamic measures... is almost correct. Why so? Well, instead of changing the individual measures, you should have created one generic measure that would use the other ones in its body with SWITCH. I don't know if you noticed but the way you did it makes the visual incorrect. How? Well, if you only select one of the measures in the slicer, one measure is producing its line but - AND THIS IS WHERE IT'S WRONG - the legend still shows the colors for all the measures! It's very misleading because the other measures do not appear in the graph, so one might think that the measures are BLANK or 0. With your setup this is the side-effect of how you code. As I said, you should have created one measure that would show the correct measure's values based on what's selected in the slicer. This will then work the way it should: non-visible measures will be removed TOGETHER with their legend entries. But the example is not the greatest for one other reason. You are changing perfectly good measures to just work with one visual. This is a no-no. It's brittle, it's ugly, it's not maintainable. On the other hand, creating a composite measure that would use the ones that already work OK is the only good way to go. You've got one place to change if a change is needed. Secondly, it's a measure that has a very concrete goal in life and if you need make changes to the other measures, they'll be reflected in the composite one automatically. Think about what's more maintainable: to have to change 20 measures because of your needs for the graph or... to have to change just one measure? The second example does demonstrate how to use FIND but such a function should almost never be used in a well-designed model. What you have is something that calls for a many-to-many relationship. Correctly coded, no FIND is needed, only relationships, which will be sooooooo much faster and cleaner. I do appreciate showing how to use FIND but I think you should also have showed how to build the model correctly, thus avoiding the ugly and not too performant FIND.
You are v-e-r-b-o-s-e, my friend. I'll summarize the issue with the first example and provide a better explanation of how to solve it: - Problem: when you select one measure in the slicer, that measure produces its line, ok, BUT the legend still shows the names and colors for all the measures, which can be misleading (a new user might think that they are BLANK or 0). A second problem is that - Alternative solution: create just one measure that contains a SWITCH statement based on SELECTEDVALUE(user_table[measures]). This is also much easier to maintain: the logic is centralized and you dedicate this special measure to a specific visual.
![Advanced DAX [Full Course]](http://i.ytimg.com/vi/ir974t0Outs/mqdefault.jpg)
You should provide a download of the data you're working with so viewers can follow along. People learn best by doing not watching.
can you plese provide us the dataset used in the video
Great stuff... hope we'll have more such advance sessions on DAX.........
where is student file for this video? please help me out
That is very well explained!! Thank you very much! 😇
Why are you using MAX function at 23:15 to select the Affected Departments column? Isn't it a text value?
Answered at 56:06. CALCULATE need first parameter as aggregate and beauty of MAX is it ignores non-numeric values and returns same value.
Really good video, I am learning a lot with this chanell
Glad you liked it! Thanks!
Why you've used MAX inside UPPER in second argument of FIND?
Very very useful video. Thank you
Thank you, great stuff
can we get a copy of pbix ?Thanks
can i get the dataset ?
many thanks
Super informative webinar. Many thanks for that.
The first example with dynamic measures... is almost correct. Why so? Well, instead of changing the individual measures, you should have created one generic measure that would use the other ones in its body with SWITCH. I don't know if you noticed but the way you did it makes the visual incorrect. How? Well, if you only select one of the measures in the slicer, one measure is producing its line but - AND THIS IS WHERE IT'S WRONG - the legend still shows the colors for all the measures! It's very misleading because the other measures do not appear in the graph, so one might think that the measures are BLANK or 0. With your setup this is the side-effect of how you code. As I said, you should have created one measure that would show the correct measure's values based on what's selected in the slicer. This will then work the way it should: non-visible measures will be removed TOGETHER with their legend entries. But the example is not the greatest for one other reason. You are changing perfectly good measures to just work with one visual. This is a no-no. It's brittle, it's ugly, it's not maintainable. On the other hand, creating a composite measure that would use the ones that already work OK is the only good way to go. You've got one place to change if a change is needed. Secondly, it's a measure that has a very concrete goal in life and if you need make changes to the other measures, they'll be reflected in the composite one automatically. Think about what's more maintainable: to have to change 20 measures because of your needs for the graph or... to have to change just one measure?
The second example does demonstrate how to use FIND but such a function should almost never be used in a well-designed model. What you have is something that calls for a many-to-many relationship. Correctly coded, no FIND is needed, only relationships, which will be sooooooo much faster and cleaner. I do appreciate showing how to use FIND but I think you should also have showed how to build the model correctly, thus avoiding the ugly and not too performant FIND.
How would you do to create a generic measure? What the generic measure would look like?
You are v-e-r-b-o-s-e, my friend. I'll summarize the issue with the first example and provide a better explanation of how to solve it:
- Problem: when you select one measure in the slicer, that measure produces its line, ok, BUT the legend still shows the names and colors for all the measures, which can be misleading (a new user might think that they are BLANK or 0). A second problem is that
- Alternative solution: create just one measure that contains a SWITCH statement based on SELECTEDVALUE(user_table[measures]). This is also much easier to maintain: the logic is centralized and you dedicate this special measure to a specific visual.
@@olemew What's wrong with verbosity, my friend?
@@dariuszspiewak5624 time is limited
@@olemew Do not exaggerate. You lose so much time during the day that you should be ashamed to even write out such rubbish like "time is limited."