Quirk in slow-moving articles query

Question

hi folks,
this question is for any of you who have written "slow moving articles" queries against the multiprovider pseudo outer join of cubes and characteristics using "constant selection" and "display non posting values." i have used it quite a bit without fail; but i have encounterd a issue with the logic when i added a second characteristic infoprovider into the mix. can anyone explain whats going on and suggest a solution?
<b>Problem statement:</b>
find products at a brand level by distributor which have no sales (for a given time frame and/or territory). allow prompting for date (or date range); territory; and/or brand.
<b>95% soultion:</b>
1)  the infocube has brand, distributor, territory, and date characteristics as dimensional components (as well as others, not required for this report)
2)  the characteristic distributor is set as an infoprovider (and has territory as an attribute)
3)  the characteristic brand is set as an infoprovider
4)  the multiprovider combines the cube, distributor, and brand.
5)  the query is written in a fashion similar to the example given at '03 tech ed: except there are 2 "number of records" key figures instead of 1; one restricted to the distributor infoprovider (const selection & display values not posted) and the other is restricted on the brand infoprovider (const selection & display values not posted)
<b>The Issue:</b>
it works fine if the variable for brand is left blank and after the report displays utilize the interactive report filter in the navigation block on brand to specify the targeted no-sale item.  if we put the target brand in the the initial variable prompt it will show the no-sale items along with the brands that did sell as no-sales. (note: that the only difference between the 2 above scenarios is whether the target brand is requested initially in a variable or as a follow-on navigation step in the report)  i know what it is doing to get erroneous results i just don't understand why, both scenarios should result in the same report. my only guess is the differences in the query caches. the examples below show the 2 scenario results.
<u>Example multiprovider data</u>:
Distr....Brand......QtySold
1001....A............10
...........B.............2
...........undefined    
1002....undefined    
1003....A.............0
...........undefined    
1004....undefined    
the above table shows the join from the multiprovider with the 2 constant selections. this works! when there are sales the brand and amount will show; also, there is an "undefined" brand for every distributor (from the constant selection) and every distributor appears for the chosen territory (from the  distributor constant selct). the correct result shoud be
1002, 1003, and 1004 as they all have zero values for
brand "A"
<u>Scenario 1</u>:  search for 0 sales of A, target brand "A" entered into <b>variable prompt</b>
Distr....Brand......QtySold
1001....undefined
1002....undefined
1003....undefined
1004....undefined
in this scenario, the condition gets rid of the "1001 A 10" but keeps the "1001 undefined 0" for an incorrect final result.
<u>Scenario 2</u>:  search for 0 sales of A, target brand in follow on <b>navigation</b>
--->step1:  initial display
Distr....Brand......QtySold
1001....A............10  
...........B.............2  
...........undefined      
1002....undefined      
1003....A.............0  
...........undefined      
1004....undefined      
with the initial run or the query all brands from the cube's transaction display along with the added "undefined" brands from the brand constant selection.
--->step 2: filter on brand A in report.
Distr....Brand......QtySold
1002....undefined
1003....undefined
1004....undefined
when the report filter is run against the brand char in the navigation block the target brand, "A", and the "undefined" brand aggregate so the condidtion takes out the non-zeros correctly.
Any ideas?

Answer 1

yes, i have an aggregate which takes the 250 million transactions in the cube down to 28 million. thats why we average sub minute response. without the aggregate it takes from 8 to 15 minutes.
speed really isn't the issue at this point, its just the fact that executing the report with a filter value versus executing the report without the filter value then filtering that value in the report yield 2 different results.
its like me asking you to tell me all your friends names that start with the letter G. later, i ask you to tell me all your friends names; after you do that i say oh, just tell me the ones that start with G.  should be the same list n'est pas? but they are not, the first list has both friends and enemies that start with the letter G and the 2nd (2-step) list is correct.