Forum Discussion
Calculating Rolling Sum But Can't Remove Duplicates
- Anonymous6 years ago
// First of all, you should not store all data // in one table. That's not only Bad Practice... // it's also dangerous and leads to subtle bugs // you'll not be able to spot. Please ALWAYS // use correct star- or snowflake-schemas. // Second, you are counting same users many times // because you're iterating dates and for each // such date you are doing a distinct count // of the users... but on the currently iterated // day. What you should do instead is you should // select the whole period at once and then // do a distinct count of users. // The measure should most likely be only shown // when only one day is visible in the current // context, therefore it must check for the // number of days visible. // The most important table in all models is // a date table (Calendar). So, please make sure // you're doing it RIGHT. // If you have a CORRECT model, the calculation // proceeds as follows: [7D Rolling Count] = var __oneDayVisible = hasonevalue( Calendar[Date] ) var __lastVisibleDay = max( Calendar[Date] ) var __periodToCountOver = datesinperiod( Calendar[Date], __lastVisibleDay, -7, day ) var __result = calculate( distinctcount( FactTable[UserId] ), __periodToCountOver ) return if( __oneDayVisible, __result )If you want to learn a bit about CORRECT MODELS, you can try these:
https://www.youtube.com/watch?v=78d6mwR8GtA
https://www.youtube.com/watch?v=_quTwyvDfG0
Creating DAX on INCORRECT or MESSY models is not only difficult. It's also error-prone. Good model = simple, fast DAX. Bad model = complex, slow DAX. Easy as that.
Best
D
Hi there,
The data contains sensitive information, which I wouldn't be allowed to share unfortunately. I'm happy to test any and as many changes to the DAX function as possible. I'm sorry for these restrictions and appreciate your help.
// First of all, you should not store all data
// in one table. That's not only Bad Practice...
// it's also dangerous and leads to subtle bugs
// you'll not be able to spot. Please ALWAYS
// use correct star- or snowflake-schemas.
// Second, you are counting same users many times
// because you're iterating dates and for each
// such date you are doing a distinct count
// of the users... but on the currently iterated
// day. What you should do instead is you should
// select the whole period at once and then
// do a distinct count of users.
// The measure should most likely be only shown
// when only one day is visible in the current
// context, therefore it must check for the
// number of days visible.
// The most important table in all models is
// a date table (Calendar). So, please make sure
// you're doing it RIGHT.
// If you have a CORRECT model, the calculation
// proceeds as follows:
[7D Rolling Count] =
var __oneDayVisible = hasonevalue( Calendar[Date] )
var __lastVisibleDay = max( Calendar[Date] )
var __periodToCountOver =
datesinperiod(
Calendar[Date],
__lastVisibleDay,
-7, day
)
var __result =
calculate(
distinctcount( FactTable[UserId] ),
__periodToCountOver
)
return
if( __oneDayVisible, __result )
If you want to learn a bit about CORRECT MODELS, you can try these:
https://www.youtube.com/watch?v=78d6mwR8GtA
https://www.youtube.com/watch?v=_quTwyvDfG0
Creating DAX on INCORRECT or MESSY models is not only difficult. It's also error-prone. Good model = simple, fast DAX. Bad model = complex, slow DAX. Easy as that.
Best
D
- Anonymous6 years agoNot applicable
This solution looks to have solved my problem and I really appreciate your assistance on this issue. Have a great day Anonymous!
- Anonymous6 years agoNot applicableHi there.
Anonymous, would you mind marking the answer to your question as THE answer, please? It's the "Accept as Solution" button under the solution... It'll help others.
Also, if you can, please add kudos to the relevant posts. This, in turn, helps the authors of the answers.
Thanks.
Best
D