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.
Related
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]
);
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.
I'm currently dealing with FoodMart DB in Mondrian.
Whenever I'm executing query which has this element:
...[Time].[Quarter].[Q1]...
...[Time].[Quarter].[Q2]...
...
After parsing the query, Mondrian always changes that query into this form:
...[Time].[1997].[Q1]...
...[Time].[1997].[Q2]...
...
Generally, both forms yield the same result. The problem is I have to keep the level from that query ([Quarter]) in order to achieve all its member later. What I mean is that I need to execute this kind of query:
...[Time].[Quarter].Members...
which apparently its result can not be achieved from this form:
...[Time].[1997].Members...
Does anyone know how to set Mondrian to keep my original query form? Or are there any way to get the level name ([Quarter]) from the given level ([1997]) ?
Thanks a lot!
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.