Just wondering if anyone had encounter this situation, that calculated table returns no row, but when evaluating the DAX it returns correct result.
In one of my tabular models, I created several summarized tables to improve query performance. The summarized table linked to the project table by project ID. I also have a row level security applied on project table.
For some reasons, I was told the report does not work. When I use SSMS to browse the tabular model via user's account, I found that if I evaluate the table directly it returns no row, e.g.
evaluate my_summarized_table
But, if I evaluate the formula directly it returns correct result, e.g.
evaluate Filter(Summarize(mytable, 'Project'[Project Id]...))
I tried to use SQL Profiler and $system.Discover_Sessions but could not figure out what is the difference between the calculated table and the raw DAX query.
Had anyone have this situation before? What could be the possible reason for that?
Related
I'm new to MDX coming from the world of SQL and I am trying to understand the concept of 'ALL'. I am understanding that 'ALL' is a single member, creating a cube with low granularity as far as that dimension is concerned. Is this correct?
What are some examples of SQL that can help me reason about this concept? Of course, SQL uses tables not cubes, but I'm sure there are some similarities which can help me make the connection? Let me try to create an example.
Let's say I have a table with such a schema representing a cube with 3 dimensions:
myTable (dim1_attribute1,dim1_attribute2, dim2_attribute1,dim2_attribute2,dim2_attribute3,
dim3_attribute1,dim3_attribute2,dim3_attribute3)
What kind of SQL would give me an aggregate with 'ALL' granularity on dim3?
'ALL' means that basically you are taking into account all members of that dimension - you are not slicing cube with some particular member of that dimension. In SQL query equivalent would be to omit dim3 from the where clause altogether, so you are not filtering your resulting aggregation with some particular value from dim3 but you are taking all rows into account.
Just to give you an overview I am very new at SSAS cubes and MDX Calculations in general. I'm currently having a hard time grasping the concept of querying an OLAP Cube.
So say I have a Movement Dimension with a unique key MovementID. I'm trying to create a calculation in SSAS that counts The total different MovementIDs in this dimension. So a few questions
Can I create this using the New Measure option in SSAS? It throws me an error if there is a MovementID in the dimension that is not present in my fact table so I'm trying to instead do this in MDX Calculation. Is my understanding here correct?
How do I make this script in MDX SSAS Calculation? The SQL equivalent should simply be SELECT COUNT(PFNo) FROM Dim_Movement. I know that the OLAP query works on axes rather than traditional table format. So how can I achieve a simple DISTINCT COUNT of a column in MDX script?
If I were to make the script to compute the SUM of the DISTINCT COUNT of the column instead. What would the script look like?
Thanks!
I am testing Pentaho 5.3 with Impala. My schema defines a dimension by relating it to its dimension table. However, when I try to use the Filter mondrian tries to obtain the dimensions from the fact table and since the table it is big it takes a long time just to load the dimensions to filter by. I do use the approxRowCount in my dimension definition.
I also have an instillation of Pentaho 5.0 with PG using a similar dataset and exact same schema and when I use the filter dimensions are loaded instantaneously. So it seems to me the issue is not schema related.
Could anyone tell me if this behavior (when trying to use Filter mondrian aggregating dimension data from the fact table instead of dimension table) is due to Pentaho settings or what could cause it?
Thank you in advance!
If anyone else ever wonders about this behavior it could be related to the fact that joins are much more efficient in PG than a NoSql database like Impala. I though that when using the Filter mondrian obtains the dimensions from the dimension table if provided with one. However, it seems it does a join of dimension and fact table before displaying dimensions.
Hope that helps!
I have a dataset that was build using MDX (analysis cube). I have a table with few columns. Now, I need to add one more column with specific data that is available in sql db and not cube. I know it is not possible to do that. What can I do to work around this issue?
Thank you
Hopefully you've using 2008R2, so you can use the LOOKUP or LOOKUPSET functions to match items from one datasource to another:
http://blog.datainspirations.com/2010/04/07/sql-server-2008-r2-reporting-services-look-up-part-iii/
It was released two years ago, so hopefully you're up to date?
You can, for each rows in your table, define a subreport that pulls the data from sql server based upon the mdx dataset. Note that the query to sql server will be made as many times as the number of records in your mdx dataset.
I want to use an MDX drill through command but i also want to join it to some SQL tables as well.
that is there will be an Id in the fact table and not a lot of other data I want to join this on to another table or view and produce a report based on those ID's returned in the drill down.
Ideas?
MDX won't do this directly. The only way I can think of doing this would be to retrieve the recordset from the drillthrough (which can be done with ADO), load it into a temporary table and join it against whatever else you want in a query.
The other option is to widen the drillthrough (if the dimensions have the data you need) and get the fields from that. Note that SSAS2005+ can support multiple drillthrough actions.
This MSDN article has some code snippets that demonstrate working with record sets returned from a drillthrough.