I'm using SQL Server Analysis Services.
I have a calculated member that, for now, just does this:
[MyDimension].[MyOnlyHierarchy].CurrentMember.Properties("MEMBER_UNIQUE_NAME")
Previously, I had just written [MyDimension].[MyOnlyHierarchy].CurrentMember.UniqueName. They should be the same anyway.
Now, I used SQL Profiler to get ahold of the query my application issues. For a simple calculated member in [MyDimension].[MyOnlyHierarchy] that just sums to different members, say with IDs 401 and 402, I get this result:
[MyDimension].[MyOnlyHierarchy].&[401][MyDimension].[MyOnlyHierarchy].&[402]
In other words, it is as if AS evaluates the underlying members and concatenates the results, rather than giving me the unique name of the calculated member...
The REALLY strange thing to me is that when I take the original query, and prepend the following:
WITH MEMBER [Measures].[GiveMeCalculatedMemberUniqueName]
AS
(
[MyDimension].[MyOnlyHierarchy].CurrentMember.Properties("MEMBER_UNIQUE_NAME")
)
...rest of query
I get the CORRECT results using this second measure! The context is the same (to me at least). Everything is the same... Yet the measure declared in the project file gives a different result than this inline calculated member.
What's going on here? Note, I've redeployed 10000 times, and I've checked the actual definition in the cube on the server and everything. It just doesn't make sense to me.
Calculations are evaluated based on solve order. may be because you moved it down and it was how the solve order was supposed to work it gives you correct result . I have a little blog on solve order here but there are many more articles on internet.
HTH
Funny... I've been sitting for about 2-3 hours with this, exploring every thought; then, after I post this question I decide to try one more thing:
move the calulated member definition to the bottom of the calculated members script file in the project.
This now gives the correct result.
Related
I'm getting a result from my cross join thay I can't wrap my heads around, see my first MDX query that gives me a result as expected. (SQL Server Analysis Services 2012)
Alright, now I want to do the same thing, only I want to target a specific date, let's take "2020-05-05". This is what happens:
I get an empty result, why don't I see the the results from the first query (limited to the rows with 2020-05-05)? I really do not understand this.
Turned out that the SSAS Cube was only partially processed, doing a full process of everything seems to have solved the problem.
Altough, I would still appricaite an explanation on why the second query failed? The first query shows quite clear that the cube, at that state, contained information on 2020-05-05?
For the life of me I cannot figure out why MDX defines dimensionality per-attribute on a dimension rather than on the key. Perhaps I'm misunderstanding something here, but it seems like a very odd way to do this if I'm understanding things correctly. Let's say I have the following data:
Person
ID (Key)
Name
Age
And I have some data like this: [('Tom123', 'Tom', 15), ('Brad456', 'Brad', 16).
Now, why I could select the two users the following two ways:
{Person.Name.Tom, Person.Name.Brad}
Or:
{Person.ID.Tom123, Person.ID.Brad456}
But not the following way:
{Person.Name.Tom, Person.ID.Brad456}
Yet all three use the same 'dimension' and even 'dimensionality' since all three ways uniquely address the same two Person entities!
This seems so odd to me, in that they are both using the same 'dimension' and 'dimensionality' and should be able to use the Key for that dimension rather than thinking each attribute is unique. Why is this so? Or, am I misunderstanding something in this.
If we use this image:
Why would it matter if we address the individual cube (tuple) by doing: {Product.TV, Geography.Asia, Time.Q1} or doing {Product.TV, Geography.Asia, Time.Quarter One}. They're just two ways of doing exactly the same thing but yet MDX considers them different dimensionality (?).
That is an excellect question.
Yet all three use the same 'dimension' and even 'dimensionality' since
all three ways uniquely address the same two Person entities!
This seems so odd to me, in that they are both using the same
'dimension' and 'dimensionality' and should be able to use the Key for
that dimension rather than thinking each attribute is unique. Why is
this so? Or, am I misunderstanding something in this.
So for any language, the syntax is checked before anything else. The case you are refering is the only instance where Dimensionality can be ignored. But it will not be wise for a language to go evaluate the data first(in terms of SSAS and MDX its called AttributeID). Secondly this will be more confusing to a user. building on your example
{Person.Name.Tom, Person.ID.Brad456}
lets we have 100 people in Newyork, so as per your logic the following
the set will be {Person.City.Newyork}, then MDX will replace all 100 IDs. This would prevent MDX from using Aggregates, which is the biggest advantge of a CUBE. Mostly the queries sent to a Cube are targeted towards summarized data. Most queries in MDX would need data of entire NEWYORK rather then a single person in NEWYORK
So to summarize, the compile time will increase and the Aggregates will not be useable.
When i run MDX query like:
select {[Measures].[all_accounts]} ON COLUMNS,
{{[Country].[Country].[Country].&[italy]}*
{[TD].[TD].[date].&[2016-09-02T03:00:00.000]:[TD].[TD].[date].&[2016-09-02T03:08:00.000]},
{[Country].[Country].[Country].&[Germany]}*
{[TD].[TD].[date].&[2016-08-16T04:00:00.000]:[TD].[TD].[date].&[2016-08-16T04:03:00.000]}}
ON ROWS
FROM [cube]
i get an error because 'italy' is not an entity found in Country dimension.
and no result is coming back.
i want to be able to run the mdx without necessarily knowing the entities names in the dimension and get back a result only for those that exists. in this example 'Germany'. how can i overcome this problem?
You can change the configuration of the server, icCube.xml, to convert not found members to null (it's risky).
icCube.mdxEvalUnknownMemberError
If you do not want to change this setting for the whole server you can use an annotation with each MDX query. For example, the following query will not return anything for the missing &[_FR] member:
//#prop( icCube.mdxEvalUnknownMemberError = false )
select {
[Geography].[Geo].[Country].&[FR_],
[Geography].[Geo].[Country].&[US]
} on 0 from [Sales]
Not a very positive answer I'm afraid but if you use member unique names such as [Country].[Country].[Country].&[italy] in a script then you will get an error if that member is not in the cube ... I don't believe there is a workaround.
I have to add that this 'limitation' has never caused me a problem.
I trying to calculate a new field in Tableau similar to a sub query in SQL. However, my numbers not matching up when I try to do this. I am stuck at this point and I am trying to see what others have done.
To provide reference, below is the subquery that I am trying to duplicate in Tableau.
select
((sum(n.non_influenced_sales*n.calls)/sum(n.calls))-(sum(n.average_sales*calls)/sum(calls))))/
(sum(n.non_influenced_sales*n.calls)/sum(n.calls)) as impact
from (select
count(d.id) as calls
,avg(d.sale) as average_sales
,avg(case when non_influenced=1 then d.sale else null end) as non_influenced_sales
from data d
group by skill) n
When I try to build the same calculation in Tableau, I am able to get the same results as long as I comment out the group by skill. However, when I try to group by skill, my attempts to match the number have not been working.
The closest I have come is when I try to fix the level of detail expression by using include. Tableau code:
(include [skill]:([non_influenced_sales]-[average_sales])/[non_influenced_sales]}
However, doing this or using fixed has not worked and I can't match the numbers I am getting from SQL.
FYI, Impact is an aggregated measure. I built the sub-query part in tableau by just creating separate fields for the calculation I needed. So for example
Non Influenced Sales calculated in Tableau:
avg(if [non_influenced]=1 then [non_influenced_sales] end)
However, I am not sure if this matters or not.
I have also tried creating custom sql. I am able to get a rolled up version using all of the dates correct. But when I want to get down to different dates/use other filters, things get messy real quick. I am trying to build relationships on a date level, but that hasn't worked either.
Is there an easier way to do this?
I'm trying to run the following MDX query (I'm newbie in the matter):
WITH MEMBER [Measures].[Not Null SIGNEDDATA] AS IIF( IsEmpty( [Measures].[SIGNEDDATA] ), 0, [Measures].[SIGNEDDATA] )
SELECT
{[Measures].[Not Null SIGNEDDATA]} ON COLUMNS,
{[Cuenta].[818000_001],[Cuenta].[818000_G02]} ON ROWS
FROM [Notas_SIC]
WHERE ([Auditoria].[AUD_NA],[Concepto].[CONCEPTO_NA],[Entidad].[CCB],
[Indicador].[INDICADOR_NA],[Interco].[I_NONE],[Moneda].[COP],
[Tiempo].[2010.01],[Version].[VERSION_NA])
Where 818000_001 is a base member of my 'Cuenta' dimension, and 818000_G02 is a node or aggregation. I receive the following message:
"Two sets specified in the function have different dimensionality"
What am I doing wrong? If I put the query with only base members (many) or only differents aggregations, the result is ok as expected.
Thanks in advance!
By using commas in your WHERE clause, you are trying to create a set out of members from different dimensions. You should use asterisks to make a CROSSJOIN instead.
So replace this:
WHERE ([Auditoria].[AUD_NA],[Concepto].[CONCEPTO_NA],[Entidad].[CCB],
[Indicador].[INDICADOR_NA],[Interco].[I_NONE],[Moneda].[COP],
[Tiempo].[2010.01],[Version].[VERSION_NA])
With this:
WHERE ({[Auditoria].[AUD_NA],[Concepto].[CONCEPTO_NA],[Entidad].[CCB]} *
{[Indicador].[INDICADOR_NA],[Interco].[I_NONE],[Moneda].[COP]} *
{[Tiempo].[2010.01],[Version].[VERSION_NA]})
I added curly braces though I'm not sure if they're absolutely required.
This is maybe your problem:
{[Cuenta].[818000_001],[Cuenta].[818000_G02]} ON ROWS
You have put them as a set but you can only make a set out of members with the same dimensionality. From your description it sounds like [Cuenta].[818000_G02] is being classed as a different hierarchy which is unexpected.
Is [Cuenta].[818000_G02] created using the Aggregate function? Can you swap to using the Sum function? Does the script then work?
(not a great answer - just more questions?)
{[Cuenta].[818000_001],[Cuenta].[818000_G02]}
Your problem probably lies in the above statement. As is clear, they could be from different hierarchies(which is not clear from your example and I come to that below).
Try replacing the above with
{[Cuenta].[Hierarchy1].[818000_001]} * {[Cuenta].[Hierarchy2].[818000_G02]}
where Hierarchy1 and Hierarchy2 are the hierarchies to which these members belong. (If you are not sure, just try {[Cuenta].[818000_001]} * {[Cuenta].[818000_G02]}). I am assuming that the second aggregate members may be built on a different hierarchy and thus the engine is throwing an error.
It is generally a good habit to always use the fully qualified member name because then the SSAS engine has to spend less time in searching for the member.