Does a cellset actually contain the queried values, in all cases, or does it
sometimes merely contain information to retrieve/calculate values on demand?

We have a customer situation where certain calculated members are taking an
inordinate length of time. The query appears to be pretty quick in returning
a cellset, but subsequent access to the cellset is very slow. This suggests
that processing is going back to the server when the cellset is accessed.

Not all calculated members are slow, and we're currently looking into what
the difference might be. The calculation depth is not deep (i.e. little
dependency on other calculated measures). We've tried connection string
terms such as "Execution Location=3; Default Isolation Mode=1", but with
little or no difference. During our own testing of the customer problem, we
experienced the same issues even with the client and server on the same
machine - suggesting network isn't an issue. Our access is via ADOMD.

Any suggestions gratefully received.

Tony Proctor

Hi Tony,

Look if the query creates a lot of subquery's (you can check that in the
query log, sample interval 1) to get your results set. If yes you can try
;cache policy = 7; connection string.

Prior to SP3, when the client formed a request to the server, the slice
portion of that request could contain at most one member for each
dimension. As a result, when the query requested members scattered at
multiple levels of a dimension, there was a high likelihood that Sonar
would generate many requests to satisfy the query. With OR query
functionality enabled, the slice can contain an array of members for each
dimension. This can significantly reduce the number of requests sent by the
client for a given query.

This only works for MOLAP.

HTH,
Bas

"This posting is provided "AS IS" with no warranties, and confers no
rights."

It's probably a bit late to be asking this now Bas. However, we can't find
any documentation on what the "cache policy" setting does. MSDN simply says
"reserved for future use". It doesn't appear to be having much of a
measurable effect in this instance. Any chance you could point me to the
necessary information?

Tony Proctor

""Bas Kersten [MSFT]"" <bask (AT) online (DOT) microsoft.com> wrote