Isn't this functionality just a hack?
There should only be one way to return a number from TM1 and that is via a reference to a dimension member.
Otherwise you lose control of what results the system is returning. This is one of the main reasons that companies move from spread sheets to systems, one version of the truth and all that good stuff.
I once worked somewhere where a set of users were all setting up the same named private subsets on their user accounts so that they could generate their own reports, no thanks!
Another occasion where this logic caused a big issue. A year consolidation called '2017' and a subset called 'Yr 2017' containing the consolidation and all of its children. End-user writes a report and un-intentionally references 'Yr 2017' and doubles all the results.
How many reports do you have in the wild that could be referencing a subset name in error or by design? Unknowable...
Do you have anyway to know which subsets are being used in reports and so need to be looked after or updated? Unknowable...
Does this concern you? It should...
The only way I can guarantee that my reports return the correct results is to have them reference dimension elements only.
I'd love to have a cfg that turns this functionality off, for me it is just wrong and represents a backdoor that just should not be available. Maybe you could make it available on a dimension by dimension basis.
I have a subset that refreshes nightly .
Is there a way i can refer that subset in a dbrw to retrieve cube value .
Why not re-build the consolidation at the same time as you build the subset?
That said vovanenok's use case of a dynamic MDX consolidation could be useful as you can change the result of a subset driven consolidation without running code. I'm not sure that I have ever felt the need for this, I expect if I had the thing that was changing that would have driven the MDX was being changed in TI anyway and so I would have rebuilt the consolidation at the same time.