Problem with Large D-List

[robinka]

Has anyone successfully used a D-List of 10,000 members in a Contributor application?  We're having a problem due to an EP limitation of 200 calculations on a cube with breakback enabled.  We're on 8.2.  Of course, Cognos Support just tells us that the cube is too big.  Any help would be appreciated.

[cbrandt]

And of course Cognos support is somehow right ;).
You can build way too big cubes in Cognos Planning and make them work somehow, but are they gone be maintainable and will you be happy in the mid-term/long-term???
Usually you go better in a long run if you think about a design change when face sizing issues in EP.
And I start to get sceptical, if people have to "enter" data for 10000 items. That is most of the times an indicater that either the planning process needs to be revised, the design can be improved or something could be automated (maybe outside of planning, i.e. using an ETL tool).

Anyway, if you still need to get it working, I would reduce the number of subtotals, if possible. Sometimes, reducing the number of hierarchy levels can help. Or split the hierarchy and if you need to do breakback use a high level cube and push it to a detailed cube.

Cheers

[tish1]

I can only agree with cbrandt. Cognos EP is a little limited when talking about large models. But in general a dimension with 10.000 elements does not belong into a planning model.
How many cells does the cube have, you are talking about?

[bronsonhg]

If you really need to use such a large d-list, here are a couple of things that worked for me (we have a products d-list of about 6,000 items). 

First of all, look at the other dimensions in the cube you’re trying to use.  Are they all necessary?  Can any of them be turned into a virtual dimension?  For us, each product is used by only 1 department, so I turned Department into a virtual dimension in one cube where we were just setting up standards for each product (like price).  Can any of the other dimensions be reduced?  We also have departments that are indirect, so they don’t have any products linked to them.  I set up a Direct Departments d-list, which is much smaller than the Master Department d-list.  I use the smaller d-list with any cube that has a Product dimension.

Also see if the d-list can be split for part of the application (i.e., the part where you do all the calculations).  For us, we have 3 analysts, each assigned to specific departments.  So I created a products d-list for each analyst, which contains only their products.  (It’s kind of a pain because when we add a product, you have to remember to add it to the master products d-list, AND to the individual analyst d-list, but it works.  And the analysts are happy the cubes load faster and they don’t have to sort thru a bunch of stuff that’s not relevant to them.) 

Anyway, the analysts make adjustments in their individual cubes, then the results are linked to a Summary cube, which has ALL the products.  The Summary cube is really only used to pull totals from, and for reporting, so there aren’t too many calcs.

Hope this gives you a few ideas.  Good Luck.