When we define user hierarchy, Unknown Member may have regular member under
it if attribute hierarchy
is processed with NullProcessing property to "UnknownMember".

For example,

A

Here, we can refer to Unknown Member variously using UnkownMember as
following,

[A].UnknownMember

[A].UnknownMember.UnknownMember

[A].UnknownMember.UnknownMember.UnknownMember

[A].UnknownMember.Children

However, next does not work. It causes parsing error.

[A].UnknownMember.[M1]

But if you set UnknownMemberName (for example, to Etc) and use it, next
work.

[A].[Etc].[M1]

Is it by design or bug?


Ohjoo

Actually both.

When you use the UnknownMember capability, under the covers it's generating a key like this:
.UNKNOWNMEMBER

That can lead to keys like (in your example):
.&[A].UNKNOWNMEMBER.&[M1].

Parts of the syntax engine haven't been coded with this senario and will return an error (incorrectly). However, the query engine seems to be able to return the values fine.

In the case you outlined, I suspect what's happening is you're passing the values WITHOUT the ampersand (&), and so the engine is doing a name lookup (instead of a key lookup). This passes the syntax engine and is executed.

NB: Name lookups are of course inherently slower. On a small dimension it's not very significant but on larger dimensions (i.e. +10,000 entries) it starts to bog down.

P.S. I contacted Microsoft a few years ago on this issue and they claimed it's "by design". Since it's perfectly good syntax (the engine just doesn't recognize the reserved keyword properly), you be the judge.