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.
Related
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.
Is it possible to use an aggregated named set to filter queries in MDX? I don't want the set items in the result set so moved it to the WHERE, however this seems to cause all measures to return (null).
First, I build a set using a couple of members from a staff hierarchy:
WITH
SET [Combined] as {
[Staff].[Group].[Practice Group].&[04],
[Staff].[Group].[Practice Group].&[06]
}
Then I aggregate that set into a new member:
MEMBER [Staff].[Group].[Group Combo] AS Aggregate([Combined])
Usually I would then use this in my query as a reporting area, possibly with hierarchize (depending on the query) and everything is fine. However this time I needed to filter the data based on this combination of members e.g:
WHERE ([Staff].[Group].[Group Combo])
This gave me (null) values and if I used [Combined] I received a cyclical reference error, however using the below worked fine:
WHERE ({[Staff].[Group].[Practice Group].&[04],[Staff].[Group].[Practice Group].&[06]})
Am I overlooking something here? Or using the wrong approach? Maybe it is just a quirk of the cube I am querying?
I would say that the behaviour is related to the order in which the processor is executing the clauses within your query:
Logical order an MDX query is processed
WHERE happens before WITH
You mentioned that the following works fine - specifying explicit members in the where clause it is pretty standard and fast:
WHERE ({[Staff].[Group].[Practice Group].&[04],[Staff].[Group].[Practice Group].&[06]})
You could add it to a sub-select just as it is on the 0 axis:
SELECT
...
...
FROM
(
SELECT
{[Staff].[Group].[Practice Group].&[04],[Staff].[Group].[Practice Group].&[06]} ON 0
FROM [YourCube]
);
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'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.
I'm using a query of the form:
Select {
([Measures].[M1], [Time].[2000]),
([Measures].[M2], [Time].[2000]),
([Measures].[M1], [Time].[2001]),
([Measures].[M2], [Time].[2001])
} on 0
From [Cube]
Where
([Some].[OtherStuff])
using Analysis Services 2008. Even though I'm not specifying NON EMPTY or similar, I'm still only getting three of the cells back (one of them is null).
How do I make sure that all the cells are brought back - even null ones?
Additional thoughts:
The query above isn't actually the one I'm running (surprisingly enough:) ). The real one has a couple of hierarchies from the same dimension specified as part of the select, and also as part of the where clause. I'm wondering if it's something to do with that, but I can't think what exactly.
Additional additional thoughts:*
This seems to be an AS2005/8 feature called Auto-Exists. Have a look at the relevant section on this MSDN article.
You're pulling back different dimensions, which doesn't fly too well. Try this instead:
with
member [Time].[Calendar].[CY2000] as
([Time].[Calendar].[2000], [Time].[Fiscal].[All Time])
member [Time].[Calendar].[FY2001] as
([Time].[Calendar].[All Time], [Time].[Fiscal].[2001])
select
{[Time].[Calendar].[CY2000], [Time].[Calendar].[FY2001]}*
{[Measures].[M1], [Measures].[M2]}
on columns
from [Cube]
where
{[Some].[OtherOtherStuff]}
Not an answer but this should help narrow down the problem, a query that replicates the issue in AdventureWorks
SELECT
{ ( [Date].[Calendar].[Date].&[1], [Date].[Fiscal].[Date].&[1129] ) } on 0
FROM [Adventure Works]
I'd expect this to bring back the tuple specified and a Null, but instead no tuples are retrieved.
I think this is because the tuple located on two hierarchies of the same dimension where there is no commonality.