Thanks for testing and confirming TM123 - appreciated.
I am still cautious of using undocumented features as they could potentially stop working with any future upgrade. They also make it a bit confusing when handing over to another resource who is not aware of them.

Not quite true. The bTemporary flag is optional. If creating a temporary subset then the flag must be the 3rd argument and the optional dimension name becomes the 4th. However if the bTemporary flag is omitted (and therefore has default value of 0) then dimension name remains the 3rd argument. To implement otherwise would have broken backwards compatibility.

Not quite true. The bTemporary flag is optional. If creating a temporary subset then the flag must be the 3rd argument and the optional dimension name becomes the 4th. However if the bTemporary flag is omitted (and therefore has default value of 0) then dimension name remains the 3rd argument. To implement otherwise would have broken backwards compatibility.

Thanks for testing and confirming TM123 - appreciated.
I am still cautious of using undocumented features as they could potentially stop working with any future upgrade. They also make it a bit confusing when handing over to another resource who is not aware of them.

Hope this at least gives others options on dealing with the issue.

That is true and I have that concern also! There are some good undocumented features such as specifying SubsetNames in CellGetN ( and also DBRW ) instead of ElementNames, and I currently use this feature a lot

That is what I exactly said When Creating Temp Subsets, the DimName argument should be placed in 4th place, Like in your third example: SubsetCreatebyMDX( sSubName, sMDX, bTemporary, sDimName );

I interpreted your answer as saying that sDimName had to be the 4th argument. That is, I thought you said if you don't want to create a temporary subset you would need to use ...
SubsetCreatebyMDX( sSubName, sMDX, 0, sDimName );
Which you could use (but why would you). As if you wanted to create a non-temporary object then the 3rd argument can just be omitted and use ...
SubsetCreatebyMDX( sSubName, sMDX, sDimName );

I was just making it clear that there is no need to re-factor any processes using SubsetCreatebyMDX with sDimName argument as they won't break on upgrade.

Please place all requests for help in a public thread. I will not answer PMs requesting assistance.

That is what I exactly said When Creating Temp Subsets, the DimName argument should be placed in 4th place, Like in your third example: SubsetCreatebyMDX( sSubName, sMDX, bTemporary, sDimName );

I interpreted your answer as saying that sDimName had to be the 4th argument. That is, I thought you said if you don't want to create a temporary subset you would need to use ...
SubsetCreatebyMDX( sSubName, sMDX, 0, sDimName );
Which you could use (but why would you). As if you wanted to create a non-temporary object then the 3rd argument can just be omitted and use ...
SubsetCreatebyMDX( sSubName, sMDX, sDimName );

I was just making it clear that there is no need to re-factor any processes using SubsetCreatebyMDX with sDimName argument as they won't break on upgrade.

Exactly, I am not currently using the Temp subset (yet) so my code still works and that was the first thing when I saw the new feature (with bTemporary being the third parameter). I thought that will make all my TIs break since I was (and I still am ) applying sDimName as third parameter