Define Detail Rows if referenced measures use it

[marcosqlbi]

Define Detail Rows if a measure depends on one or more other measures that have Detail Rows property defined.

[otykier]

Hi Marco. Just to clarify. Assume I have the following measures and dependencies:

and Detail Rows have been defined at the top-most measure [Reseller Total Sales].

Should the rule then output all measures that depend on [Reseller Total Sales] recursively, or just the measures that reference it directly? I guess in the former case, the rule could potentially output many measures that would be in violation of the rule, and it would not always be clear why, where as in the latter case, the rule would have to be re-evaluated continuously while new Detail Rows expressions are added...

[marcosqlbi]

Good point. I think that providing the warning at the first level is the right thing to do. However, we should figure out how to "disable" the warning for specific measures. I don't know whether we might use some annotation or some comment in the measure. For example, if it's ok that Total Sales doesn't provide the warning, I would like to mark Total Sales in some way, so that Reseller Current Quarter Sales still generates the warning (unless I disable that measure as well).

[otykier]

This is already possible today. In the screenshot below, you can see that I've already ignored the rule for the [Total Sales] measure (shown in the Property Grid). As you can see, an annotation has been added to the measure, specifying the ID's of the rules that should be ignored:

One more question: Should the rule ignore measures residing on a table that has a Default Detail Rows Expression defined?

[marcosqlbi]

Believe it or not, I missed the "Default Detail Rows Expression"!
Ok, I would do the following (but I'm very open to discuss it because I never spent too much time on this):

• a measure A residing in a table X that has "Default Detail Rows Expression" is like a measure that has "Detail Rows Expression" defined locally on the measure (with one exception)
• a measure B residing on table Y that depends on A should show the warning if "Detail Rows Expression" is not defined in B (regardless of the default in Y) --> however, for this case an "ignore rule on derived measures" applied to A could be useful.
• a measure B residing on table X that depends on A should show the warning if a specific "Detail Rows Expression" is defined in A (regardless of the default in X) - this is the exception to the first rule (do you see my point for this case?)

Feedback is welcome - we are in unexplored territories here.

[otykier]

I agree with your 3rd bullet, since we have to assume that, in general, if measure B depends on A, it must mean that B is a more "specialized" case of A. And so any "specialization" (in this case, Detail Row Expression different from the table default) that has been explicitly set on A, should also prompt us to consider doing something to B.

[marcosqlbi]

This is also my feeling. Not sure how it can be implemented, but it is a "nice to have" feature,