Using parent child dimension, non-leaf data hidden, No All Level, for one
dimension allows me to properly load aggregate data but when I introduce a
second dimension with the same properties the result is double counting of
the aggregate item (i.e. roll-up is occuring on the aggregate items for the
new dimension).
Is there a work-around to achieve this?
I have a small illustrative example mdb source and cab if required.

Sounds like there is a problem with the relationships in your star
schema. You don't by any chance have the two dimensions join on the one
column in the fact table do you? This would produce duplicate rows when
AS issues the select statement joining the dimensions to the fact table.

If you examine the SQL statement that is emitted during processing you
should be able to see the issue. You might find that you need to chain
the dimensions or use a view to create a second column to join on.

If you want more specific help your sample would be of assistance. You
can contact me off line via the contact page on my blog if you want.

HTH

--
Regards
Darren Gosbell [MCSD]
Blog: http://www.geekswithblogs.net/darrengosbell

In article <8A9A9D34-B518-418A-A2B5-FF0994F9E5BF (AT) microsoft (DOT) com>,
Ronna (AT) discussions (DOT) microsoft.com says...

Thank you for the prompt reply. No I have a straightforward schema. No two
dimensions point to the same fact table row and I have checked the select
statement generated by the cube processing and it is simple and looks correct.
I would like to send you my small reproducable example. I've responded via
your blog page.
Thanks

"Darren Gosbell" wrote:

Are you running into the issue discussed in the following thread?

http://groups.google.co.uk/group/mic...510f5a2eb73851

HTH,

Chris

--
Blog at:
http://spaces.msn.com/members/cwebbbi/


"Ronna" wrote:

Yes, thank you. This solution works. I had tried it already by editing my
existing custom rollup
formulas that way - but got #ERR. When I actually deleted the original
dimesions and created new ones this way it worked.
And consequently, since these 2 dimensions now only make sense when (a) used
together and (b) on a certain fact table, they must become private dimensions
of the cube instead of shared dimensions.
Thanks again,
R

"Chris Webb" wrote: