Showing posts with label accessing. Show all posts
Showing posts with label accessing. Show all posts

Sunday, March 25, 2012

Calculated Measure And Drill Through

I am getting the error below in Proclarity:

"Error Accessing Drill To Detail Information

xxxxxxx in dimension Measures is a calculated member."


Can AS2005 support drill through from a calculated member, if not is there a work around?

Thanks

The answer is pretty easy but you might not like it: The drillthough is not supported on the calculated measures or calculated members.

Not sure what would you expect from the drillthoguh into calculated measure or member. Calulated member could be totally unrelated to the facts in your cube. How would you drillthorouh into that? You can definitely can come up with simple case of calc measure being sum of two measures in the same measure group, but that is very narrow and not practical case.

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

Sunday, March 11, 2012

Caching with Dynamic Security

I defined one role in my AS database with dynamic security for each dimension. I am accessing the AS database in an ASP.NET web application which runs under a domain user and uses Form Authentication. Therefore I always connect to the AS database under the same domain user even though security should be based on the user logged into the web application. When I run a MDX query, I pass along the web user's security info as part of the connectionstring and uses dynamic security to get the AllowedSet for each dimension. However, I notice my user defined function is ran only on the first time I run a query, meaning the dimension security is cached based on the domain user in the connection string and not the web user. Sorry if this sounds confusing but I can clarify a bit more if needed. My question boils down to: Is there a way to tell AS database to cache result base on the CustomData property of the connectionstring?

The answer is YES - AS is smart enough to recognize that different values of CustomData were used even though the real identity on the connection is the same. Since the main purpose of CustomData was for custom authentication - it is treated the same as different users. Same is true w.r.t. Roles and UserId properties.

HTH,

Mosha (http://www.mosha.com/msolap)

|||

Mosha,

As always, you are right and thanks for the help. I did a little more testing after my post and realized AS is caching the result base on the CustomData property. Thanks!