Why not use the "where clause" for filters instead of "on pages"?

Short answer: In SP1 the PPS Planning add-in will use the where clause and life for MDX experts will be back to normal.*

Long answer: Because of the extra properties needed for writeback. The CellSet returned by AdoMd.Net does not return member properties for members specified in the where clause. What additional properties the add-in needs is a topic for another post. In many cases nobody notices that by putting the filter selections on pages (which is more like a crossjoin of a single element than a where filter) that there is any difference in the filter. But everybody notices when they take try to run the Matrix query in most other MDX tools like SQL Management Studio:

Executing the query ...
Obtained object of type: Microsoft.AnalysisServices.AdomdClient.CellSet
Results cannot be displayed for cellsets with more than two axes.
Execution complete

(Trust me, that display error irritates me an awful lot, just so you know I feel your pain if you don't like this. It's definitely something I am very excited about in SP1 that won't impact many users. But for the troubleshooters I think it is a fantastic luxury to just cut and paste the query for a change...ok you will still have to search and replace $CurrentPeriod$...)

In the matrix itself we don't really render a multi-dimensional result, we just render the first slice so that it looks like a 2D result. (And for our query we try hard to make sure that the 3D result we produce only has a single slice returned which is equivalent a 2D result and no extra data is queried other than the member properties).

So in practice the "on pages" approach worked well to simplify the rendering engine at first. But crucially there are some cases we've found where it degrades performance of the MDX query. And at least in current builds of AS2005 that PPS depends on, the cost of running an extra query to retrieve the missing member properties is negligible. So we were able to make this change in SP1. There simply wasn't enough time for us to have made this change earlier - and I don't remember if when we were working with pre-release versions of AS2005 if the second query for properties was always of negligible cost.

Another convenient side effect of this change in SP1 is that the filter selection is now conveniently available in custom MDX scenarios...but that, of course, is another post.


* As of this writing I can't promise any dates for SP1. All I've seen is what it pretty commonly known: spring 2008. We of course have an internal schedule and targets, but software releases are not easy. When the date is known and "official", It will be posted quite widely, on clearly "official" microsoft.com sites, including the technet forums as soon as there's an official date. (Oh and don't worry, asfaik the core PPS dev/test/pm team is based in the northern hemisphere so spring isn't 6 months away.)