RESOLVED: Multiple Optional Prompts for Slicer

[adam_mc]

I have two optional prompts to create slicers (set up as below) over a Transformer Cube:

Slicer1:  #promptmany('parm_Store', 'memberuniquename', '[Store Hierarchy]','set(', '[Store] ',')')#
Slicer2:  #promptmany('parm_Division', 'memberuniquename', '[Product Hierarchy]','set(', '[Division] ',')')#

Slicer1 is based on a value prompt that allows Store Selections.
Slicer2 is based on a value prompt that allows Product Division Selections.

If I make a selection from either one or neither of the prompts, things work as expected.
However, if I select from both, I am getting the total for all stores/products!

Do I need to somehow combine these into a single slicer?  If so, how?
Any thoughts?

Thanks in advance,
Adam.

[CognosPaul]

This shouldn't be happening.

First thing to do, delete the default values and then click on tools and show generated sql/mdx. Copy/paste the mdx so I can analyze it. Also check if there is any Cognos SQL and paste that in too.

What happens if you make it a prompt instead of a prompt many, and get rid of the set()? Technically slicing by a set is a no-no. Traditionally you can slice by a single member only. Most modern OLAP engines will automatically aggregate the set into a single calculated member for you at runtime, but Cognos may occasionally make some mistakes with that.

Do you have any detail filters, or functions that don't come from the dimension functions list like substring? Using non-dimensional functions may force cognos to export all of the data to do local processing. There are usually much easier ways to handle such needs.

Try a simple test xtab that just has years in rows, measures in columns, and static value slices. No functions or anything fancy. If that returns the wrong results, then the problem is in the model.

Is this a list or xtab? Lists require additional local processing to transform the data (the same way relational sources requires transformation to appear in an xtab).

[adam_mc]

PaulM...
You are correct, this shouldn't have been happening.

This was caused by "inexperienced" (read sloppy) coding in my other calculations!
Once identified and corrected, things now work as expected.

Thanks again for taking the time to try and help me, I really appreciate it.
Adam.