Dimension used ON ROWS to depend on Measures member

Here is a mock up of my script:

(0)

SELECT 
  {   
    [Measures].[Revenue],
    [Measures].[NumSignups]
  } ON COLUMNS
 ,NON EMPTY 
    {
        [Date].[Calendar Year].[Calendar Year].MEMBERS*
        [Date].[Calendar Month].[Calendar Month].MEMBERS*
        {
          [Location active].[Shop Name].MEMBERS
      //[Location signup].[Shop Name].MEMBERS
        }
    } ON ROWS
FROM [OurCube]

The Measures member [Revenue] is related to the Dimension [Location active] whereas the Measures member [NumSignups] is related to the Dimension [Location signup]. Each measure is not related to the alternative location dimension.

So both of the following, are logically wrong, and return the same number in every cell (which is as expected):

(1)

SELECT 
  {   
    [Measures].[Revenue]
  } ON COLUMNS
 ,NON EMPTY 
    {
        [Date].[Calendar Year].[Calendar Year].MEMBERS*
        [Date].[Calendar Month].[Calendar Month].MEMBERS*
        {
          [Location signup].[Shop Name].MEMBERS
        }
    } ON ROWS
FROM [OurCube]

(2)

SELECT 
  {   
    [Measures].[NumSignups]
  } ON COLUMNS
 ,NON EMPTY 
    {
        [Date].[Calendar Year].[Calendar Year].MEMBERS*
        [Date].[Calendar Month].[Calendar Month].MEMBERS*
        {
          [Location active].[Shop Name].MEMBERS
        }
    } ON ROWS
FROM [OurCube]

Is it possible to add in some conditional logic to script (0) so that I can display both measures using one script?

Solution

This is not possible in MDX. The structure of all axes has to be is fix for an MDX statement. This is like in SQL where yo also cannot have different rows of the result to have different columns. One SQL select statement has to have a fix column list across all records. E. g. you cannot have a SQL statement having column A, B, C in row 1 and 2, but column C, D, E in row 3 and 4. You would have to e. g. column A, B, C, D, E existing (possibly empty, but existing anyway) for all four rows, as SQL result sets are defined as rectangular structures. There is no such thing like "ragged arrays" in some programming languages where each row may have a different set of columns.

Likewise, in MDX, you cannot have a hierarchy existing on a few rows, and not existing on another row.

I would instead write two MDX statements and switch them in the client software depending on some user selection.