StrToMember MDX function causing a server crash

[PavoGa]

We have isolated a problem where StrToMember will cause a server crash. This may be a well known problem, but a cursory Google search did not reveal anything on it.

The code is building a subset of accounts based on values in a cube:

Code: Select all

GENERATE( FILTER( TM1SUBSETALL( [Account] ),
	LEN([mycube].([Version].[Active1], [Measure].[myMeasure])) > 0)
	, {StrToMember("[Account].[" + [mycube].([Version].[Active1], [Measure].[RollupAccount]) + "]")})

when the conditional returns a blank to the StrToMember function, the server crashes. Of course, we'll prevent that from happening henceforth, but if this has not been recognized, should it be considered a bug and reported? I think crashing the server is a bit of an extreme response to a bad argument to the MDX function.

[Drg]

you tried to put more curly braces???

Code: Select all

{GENERATE( {FILTER( TM1SUBSETALL( [Account] ),
	LEN([mycube].([Version].[Active1], [Measure].[myMeasure])) > 0)}
	, {StrToMember("[Account].[" + [mycube].([Version].[Active1], [Measure].[RollupAccount]) + "]")})}

[PavoGa]

you tried to put more curly braces???

Code: Select all

{GENERATE( {FILTER( TM1SUBSETALL( [Account] ),
	LEN([mycube].([Version].[Active1], [Measure].[myMeasure])) > 0)}
	, {StrToMember("[Account].[" + [mycube].([Version].[Active1], [Measure].[RollupAccount]) + "]")})}

Those are not necessary with functions that return a set to begin with. And the problem is occurs when the RollupAccount is blank for the filtered Account set. I would expect an error in this case (and modified the FILTER to avoid it), but think a server crash is a bit harsh. We'll report to IBM, although hopefully this is taken care of in one of the subsequent releases we do not have as of yet.

I did not see anything related to this when I googled it and wanted to put it out there for information.

[Drg]

Yes, the server crash is unacceptably cruel. But you can use the workaround using the union of two members and take only one upper one, then if the first one is empty, you can take the default one. But this is terrible in terms of finding bugs.

[PavoGa]

Yes, the server crash is unacceptably cruel. But you can use the workaround using the union of two members and take only one upper one, then if the first one is empty, you can take the default one. But this is terrible in terms of finding bugs.

I am responding to this to make sure anyone who sees does not get the wrong idea.

A UNION will not help this. In actuality, the full MDX statement in the TI uses a UNION (I use UNION in virtually all TI MDX for a couple of purposes). The problem is when the MDX submits a blank/null value to StrToMember. All the UNIONs in the world are not going to prevent that. The "workaround" (better described as preventative method) is a filter to prevent a null value hitting the StrToMember function.

[Elessar]

Hello,

IMHO this is a serious bug: any user can open Architect, write this MDX expression and crash the server.
I've already reported a similar bug: https://www-01.ibm.com/support/entdocvi ... wg1PH06648

[PavoGa]

Elessar,

Have not looked at your link yet, but I do have an update. This also happens when a bad alias is handed to StrToMember. That should not have happened in our case, but we had a bad alias stored in a cube and, Whoa Nellie! it crashed the server while building a subset off that measure.

[Drg]

Fixit on PA local 2.0.7