<div dir="ltr">There is another thing that might be relevant to this issue. Here's the formatted query you posted:<div><br></div><div><div>SELECT</div><div> NON EMPTY Hierarchize(</div><div> AddCalculatedMembers({</div><div> DrilldownLevel({[Store].[Store Size in SQFT].[All Store Size in SQFTs]})</div><div> })</div><div> )</div><div> DIMENSION PROPERTIES</div><div> PARENT_UNIQUE_NAME</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[CATALOG_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[SCHEMA_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[CUBE_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[DIMENSION_UNIQUE_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[HIERARCHY_UNIQUE_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[LEVEL_UNIQUE_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[LEVEL_NUMBER]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_ORDINAL]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_UNIQUE_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_TYPE]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_GUID]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[MEMBER_CAPTION]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[CHILDREN_CARDINALITY]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[PARENT_LEVEL]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[PARENT_UNIQUE_NAME]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[PARENT_COUNT]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[DESCRIPTION]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[IS_PLACEHOLDERMEMBER]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[IS_DATAMEMBER]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[DISPLAY_INFO]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[VALUE]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[$member_scope]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[$scenario]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[CELL_FORMATTER]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[CELL_FORMATTER_SCRIPT]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[CELL_FORMATTER_SCRIPT_LANGUAGE]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[DISPLAY_FOLDER]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[FORMAT_EXP]</div><div> ,[Store].[Store Size in SQFT].[Store Sqft].[KEY]</div><div>ON COLUMNS</div><div>FROM [HR]</div><div>CELL PROPERTIES</div><div> VALUE</div><div>, FORMAT_STRING</div><div>, LANGUAGE</div><div>, BACK_COLOR</div><div>, FORE_COLOR</div><div>, FONT_FLAGS</div></div><div><br></div><div>According to <a href="https://msdn.microsoft.com/en-us/library/ms145528(v=sql.120).aspx">https://msdn.microsoft.com/en-us/library/ms145528(v=sql.120).aspx</a>, these properties are "context insensitive intrinsic properties":</div><div><br></div><div>CATALOG_NAME</div><div>DIMENSION_UNIQUE_NAME</div><div>HIERARCHY_UNIQUE_NAME</div><div>LEVEL_UNIQUE_NAME</div><div>LEVEL_NUMBER</div><div><div>MEMBER_NAME</div><div>MEMBER_UNIQUE_NAME</div><div>MEMBER_TYPE</div><div>MEMBER_CAPTION</div><div>CHILDREN_CARDINALITY</div><div>PARENT_LEVEL</div><div>PARENT_UNIQUE_NAME</div><div>PARENT_COUNT</div><div>DESCRIPTION</div><div>IS_PLACEHOLDERMEMBER</div><div>IS_DATAMEMBER</div><div><br></div></div><div>The MSAS documentation reads:</div><div><br></div><div>"</div><div>PROPERTIES Syntax for Non-Context Sensitive Properties</div><div><br></div><div>Use the following syntax to specify an intrinsic, non-context sensitive member property using the PROPERTIES keyword:</div><div><br></div><div>DIMENSION PROPERTIES Property</div><div><br></div><div>Notice that this syntax does not allow the property to be qualified by a dimension or level. The property cannot be qualified because an intrinsic member property that is not context sensitive applies to all members of an axis. For example, an MDX statement that specifies the DESCRIPTION intrinsic member property would have the following syntax:</div><div><br></div><div>DIMENSION PROPERTIES DESCRIPTION</div><div><br></div><div>This statement returns the description of each member in the axis dimension. If you tried to qualify the property with a dimension or level, as in Dimension.DESCRIPTION or Level.DESCRIPTION, the statement would not validate.</div><div>"</div><div><br></div><div>So if this is true, and the [Store].[Store Size in SQFT].[Store Sqft] level does not explicitly define custom properties of the same name (which I am assuming it doesn't in this case), then the statement should not even validate, if I understand the documentation correctly.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 11:01 AM, Roland Bouman <span dir="ltr"><<a href="mailto:roland.bouman@gmail.com" target="_blank">roland.bouman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ingo, Luc, <div><br></div><div>sorry to interrupt but there is something that is not clear to me. </div><div><br></div><div>Ingo you wrote:</div><div><br></div><div>"<span style="font-size:12.8000001907349px">we found the line in the source code, that breaks the XMLA call. </span><span style="font-size:12.8000001907349px">Apparently in Mondrian 3.x This call was made in a different class and passed false instead of true as parameter."<br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">But the links you provide both point to Mondrian 4 source, 4.2 and 4.3 respectively.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">The relevant implementation of getProperties in </span><span style="font-size:12.8000001907349px">MondrianOlap4jLevel</span><span style="font-size:12.8000001907349px"> looks identical in both 4.2 and 4.3:</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><a href="https://github.com/pentaho/mondrian/blob/4.2/src/main/java/mondrian/olap4j/MondrianOlap4jLevel.java#L98" target="_blank">https://github.com/pentaho/mondrian/blob/4.2/src/main/java/mondrian/olap4j/MondrianOlap4jLevel.java#L98</a></span><br></div><div><span style="font-size:12.8000001907349px"><a href="https://github.com/pentaho/mondrian/blob/4.3/src/main/java/mondrian/olap4j/MondrianOlap4jLevel.java#L98" target="_blank">https://github.com/pentaho/mondrian/blob/4.3/src/main/java/mondrian/olap4j/MondrianOlap4jLevel.java#L98</a></span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">and so do the calls to getProperties in MondrianOlap4jExtra:</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><a href="https://github.com/pentaho/mondrian/blob/4.2/src/main/java/mondrian/olap4j/MondrianOlap4jExtra.java#L320" target="_blank">https://github.com/pentaho/mondrian/blob/4.2/src/main/java/mondrian/olap4j/MondrianOlap4jExtra.java#L320</a></span><br></div><div><span style="font-size:12.8000001907349px"><a href="https://github.com/pentaho/mondrian/blob/4.3/src/main/java/mondrian/olap4j/MondrianOlap4jExtra.java#L320" target="_blank">https://github.com/pentaho/mondrian/blob/4.3/src/main/java/mondrian/olap4j/MondrianOlap4jExtra.java#L320</a></span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>Ingo, can you track back and verify where you made the change exactly? Since if this part of the code is identical and worked in an earlier version then it would seem the cause is somewhere else. </div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Jun 1, 2015 at 8:53 AM, Ingo Klose <span dir="ltr"><<a href="mailto:Ingo.Klose@incuda.com" target="_blank">Ingo.Klose@incuda.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Luc,<br>
<br>
Thanks for the answer, but to be honest I have no direct access to nor any knowledge of Microsoft SQL Server Analysis Services.<br>
<br>
All I know is that the tool that we try to use to connect Microsoft Excel (XMLAConnect) has a problem with Mondrian 4 because this method is implemented differently between Mondrian 3.X and Mondrian 4. At this point me and Tom are trying to figure out the reason for this change and if it is reversible or what consequences that might have.<br>
<br>
Since we are going through Saiku as the "Server" we have another level in which we might be able to handle the problem, but it would be good to understand it better, especially from the Mondrian point of view.<br>
<br>
Best regards,<br>
Ingo<br>
<br>
<br>
Date: Tue, 26 May 2015 09:36:40 -0400<br>
From: Luc Boudreau <<a href="mailto:lucboudreau@gmail.com" target="_blank">lucboudreau@gmail.com</a>><br>
Subject: Re: [Mondrian] Mondrian 4 - Unsupported properties?<br>
To: Mondrian developer mailing list <<a href="mailto:mondrian@pentaho.org" target="_blank">mondrian@pentaho.org</a>><br>
Message-ID:<br>
<CAKTEAx8c=Qn7PydZKWeRuvGMCqiPvjXDr8Wqjfp=_naWhyfS=<a href="mailto:w@mail.gmail.com" target="_blank">w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<span><br>
I'm not sure that the solution is without consequences. According to the javadocs of the XmlaExtra interface:<br>
<br>
/**<br>
<br>
* Returns the defined properties of a level. (Not including system<br>
<br>
* properties that every level has.)<br>
<br>
*<br>
<br>
* @param level Level<br>
<br>
* @return Defined properties<br>
<br>
*/<br>
<br>
List<Property> getLevelProperties(Level level);<br>
<br>
<br>
Have you tried similar calls on Microsoft Sql Server Analysis Services? We shold compare their implementation with ours.<br>
</span><div><div>_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org" target="_blank">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Roland Bouman<br>blog: <a href="http://rpbouman.blogspot.com/" target="_blank">http://rpbouman.blogspot.com/</a><br>twitter: @rolandbouman<br>linkedin: <a href="http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro" target="_blank">http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro</a><br><br>Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6 <a href="http://tinyurl.com/lvxa88" target="_blank">http://tinyurl.com/lvxa88</a>) and "Pentaho Kettle Solutions" (Wiley, ISBN: 978-0-470-63517-9 <a href="http://tinyurl.com/33r7a8m" target="_blank">http://tinyurl.com/33r7a8m</a>)</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Roland Bouman<br>blog: <a href="http://rpbouman.blogspot.com/" target="_blank">http://rpbouman.blogspot.com/</a><br>twitter: @rolandbouman<br>linkedin: <a href="http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro" target="_blank">http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro</a><br><br>Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6 <a href="http://tinyurl.com/lvxa88" target="_blank">http://tinyurl.com/lvxa88</a>) and "Pentaho Kettle Solutions" (Wiley, ISBN: 978-0-470-63517-9 <a href="http://tinyurl.com/33r7a8m" target="_blank">http://tinyurl.com/33r7a8m</a>)</div>
</div>