Intrinsic Member Properties: The MEMBER_KEY Property

Friday Jun 20th 2008 by William Pearson

Join BI Architect Bill Pearson in an introduction to the intrinsic MEMBER_KEY property. In hands-on exercises, we gain exposure to the use of the property in generating simple lists, as well as datasets to support report parameter picklists.

About the Series …

This article is a member of the series, MDX Essentials. The series is designed to provide hands-on application of the fundamentals of the Multidimensional Expressions (MDX) language, with each tutorial progressively adding features designed to meet specific real-world needs.

For more information about the series in general, as well as the software and systems requirements for getting the most out of the lessons included, please see my first article, MDX at First Glance: Introduction to MDX Essentials.

Note: Current updates are assumed for MSSQL Server, MSSQL Server Analysis Services, and the related Books Online and Samples.


In this lesson, we will examine MEMBER_KEY, an intrinsic member property. MEMBER_KEY. As we noted in Intrinsic Member Properties: The MEMBER_CAPTION Property, the intrinsic member properties supported by SQL Server 2005 Analysis Services are of two types: context sensitive member properties and non-context sensitive member properties. MEMBER_KEY belongs to the second group of properties. As a general group, intrinsic member properties provide additional information that can be used by applications to enhance the user's experience. Support for the non-context sensitive member properties is the same for all members, regardless of individual context.

The purpose of the MEMBER_KEY property is to support the return of the member key, in the original data type, for the member with which it is associated. MEMBER_KEY can be useful in a host of different applications, particularly in scenarios where backward compatibility is a consideration; and as I have noted to be the case for other functions and properties within the MDX Essentials series, MEMBER_KEY allows us to exercise a great deal of presentation “sleight of hand,” in working with MDX in Analysis Services, as well as within Reporting Services and various other reporting applications that can access an Analysis Services cube.

The MEMBER_KEY property can be leveraged in activities that range from generating simple lists to supporting sophisticated presentations. It is a particularly effective tool when we need to provide parameter picklist support (where it can serve multiple purposes, such as an index) and the like, as we shall see. We will introduce the function, commenting upon its operation and touching upon examples of effects that we can employ it to deliver. As a part of our discussion, we will:

  • Examine the syntax surrounding the function;
  • Undertake illustrative examples of the uses of the function in practice exercises;
  • Briefly discuss the results datasets we obtain in the practice examples.

The MEMBER_KEY Property


According to the Analysis Services Books Online, the MEMBER_KEY property specifies “…The value of the member key in the original data type. MEMBER_KEY is for backward-compatibility.” The Books Online further state that the “… MEMBER_KEY has the same value as KEY0 for non-composite keys, and MEMBER_KEY property is null for composite keys.”

MEMBER_KEY has many applications, including the rather obvious uses with Analysis Services members that are included in the definition, as well as its pairing with other MDX functions to leverage its power even further. As we have seen is the case with the .Name function (among others), as well as the MEMBER_CAPTION property, in other articles of this series, MEMBER_KEY can also be synergistically combined with the .CurrentMember function; we will see an example of this combination within the practice exercises that follow.

We will examine the syntax involved in leveraging the MEMBER_KEY property after our customary overview in the Discussion section that follows. After that, we will conduct a practice example, within a scenario constructed to support a hypothetical business need that illustrates uses for the property. This will afford us an opportunity to explore some of the presentation options that MEMBER_KEY can offer the knowledgeable user. Hands-on practice with MEMBER_KEY, where we will create expressions that leverage the function, will help us to activate what we learn in the Discussion and Syntax sections that follow.


To restate our initial explanation of its operation, the MEMBER_KEY property, when acting upon a member, returns the member key of the object to which it is appended with the period (“.”) delimiter. The value returned is null for composite keys, and equates to a “.KEY0” use of the KEY(x) property (which, as we learn within the respective article within this series, returns the zero-based ordinal of the key) for non-composite keys. MEMBER_KEY can be used for a great deal more than the support of simple lists of unique object names, as we have intimated. When we couple it with other functions, we can leverage MEMBER_KEY to deliver a wide range of analysis and reporting utility.

As in so many cases with the Microsoft integrated business intelligence solution, consisting of MSSQL Server, Analysis Services and Reporting Services, this property, properly exploited within the Analysis Services layer, can be extended to support capabilities and attributes in the Reporting Services layer. Knowing “where to put the intelligence” among the various layers is critical to optimization, in many cases. For more of my observations on this subject, see Multi-Layered Business Intelligence Solutions ... Require Multi-Layered Architects.

The MEMBER_KEY property returns, as we have noted, a typed key associated with the member. If we are using MEMBER_KEY in conjunction with a member with which a composite key is associated, a null value is returned.

Let’s look at a syntax illustration to further clarify the operation of MEMBER_KEY.


Syntactically, anytime we employ the MEMBER_KEY property to return the associated key, the member for which we seek to return the key is specified to the left of MEMBER_KEY. The property takes the object to which it is appended as its argument, and returns, in the original data type, the key of the object specified. The general syntax is shown in the following string:


In short, putting MEMBER_KEY to work couldn’t be easier. When specifying the property to return the Key of a member or members, we simply append it to the right of the member(s) under consideration.

As is typically the case with MDX functions, operators and properties, the MEMBER_KEY property can often be best leveraged by combining it with other functions, operators or properties, particularly “relative” functions, to generate lists of names, and so forth, as we shall see in short order.

NOTE: For information on several of the “relative” functions, see my article MDX Member Functions: "Relative" Member Functions, within the Database Journal MDX Essentials series.

We will practice some uses of the MEMBER_KEY property in the section that follows.



To reinforce our understanding of the basics we have covered so far, we will use the MEMBER_KEY property in a hands-on example that illustrates its operation. We will do so in a simple scenario that places MEMBER_KEY within the context of meeting business requirements similar to those we might encounter in our respective daily environments. The intent, of course, is to demonstrate the operation of the MEMBER_KEY property in a straightforward, memorable manner.

We will turn to the SQL Server Management Studio as a platform from which to construct and execute the MDX we examine, and to view the results datasets we obtain. If you do not know how to access the SQL Server Management Studio in preparation for using it to query an Analysis Services cube (we will be using the sample Adventure Works cube in the Adventure Works DW Analysis Services database), please perform the steps of the following procedure, located in the References section of my articles index:

Prepare MSSQL Server Management Studio to Query Analysis Services

This procedure will take us through opening a new Query pane, upon which we can create our first query within the section that follows.

Procedure: Satisfy Business Requirements with MDX

As a basis for our practice example, we will assume that we have received another call from the Reporting department of our client, the Adventure Works organization, requesting our assistance in meeting a specific report presentation need. The client has implemented the integrated Microsoft BI solution, and, in addition to using Analysis Services as an OLAP data source, they use Reporting Services as an enterprise reporting solution. The MDX we explore together, we are told, will thus be adapted and extended for ultimate use within Reporting Services, in multiple parameterized reports. Finally, we learn that the requirements will very closely parallel those of a previous visit, documented in Intrinsic Member Properties: The MEMBER_CAPTION Property , an earlier article in this series.

Per the original requirement, we are told, our client wishes to meet a mechanical need within the reporting layer of an integrated BI application. As many of us are aware, enterprise reporting applications typically allow for parameterization (via what are sometimes known as “prompts” or “parameter prompts”) to enable information consumers to quickly find the information they need from a report. These parameters, whose values are physically passed to an axis specification or a slicer in the dataset query, often act to put filters into place “on the fly;” the “filters” are thus enacted when the consumer types or selects a value, or a series of values, at run time.

As we have noted numerous times in articles within my MSSQL Server Reporting Services series and elsewhere, there are two primary types of parameters, type-in and picklist, which can be mechanized through various means. Type-in parameters accept directly typed user input for the value upon which the report is based. An example of input might, for a report based upon an Analysis Services cube, consist of the Unique Name for a given filter, say, for one of the Customer Geography Cities within the Adventure Works sample cube.

The trouble with type-in parameters is that they are subject to input error, and thus can fail to produce the desired results if they are not precisely correct. This can be particularly cumbersome for information consumers when the report is based upon an Analysis Services cube, because the precise MDX qualified name might present a typing challenge for some.

For this reason, the alternative parameter type, the picklist, provides a more user-friendly experience. A picklist presents a selection of choices to a consumer, based upon a static file, a dataset from a larger data source, or through other means. The picklist is often the tool of choice, because of its inherent elimination of typing errors. A well-constructed picklist makes selection easy for the consumer (who is not often pleased with a long scrolling process, or other cumbersome method, as the initial step in generating a commonly requested report). An investment in developing a good picklist often pays great dividends in consumer satisfaction.

It is simple to generate a list that provides all we need to support parameterization within Reporting Services and other enterprise reporting applications. Let’s get some hands-on exposure to assembling a list whose primary objective is picklist support. We will construct a dataset upon which the picklist selections can be based, and then examine briefly an illustration of the use of this dataset in MSSQL Server Reporting Services.

NOTE: For details surrounding hands-on approaches (as you will see, they are Legion) to constructing picklists in Reporting Services, see these articles in my MSSQL Server Reporting Services series here at Database Journal:

Let’s assume, as a background scenario, that, our client colleagues extend a request that we documented in Intrinsic Member Properties: The MEMBER_CAPTION Property. As we recall, the request was a common one: they wanted to provide picklist support within an OLAP report, which they had constructed using MSSQL Server Reporting Services. The data source was to be the Adventure Works sample cube, which accompanies an installation of MSSQL Server Analysis Services 2005 (and with which most of us are familiar. Our colleagues originally asked that the selector for a parameter picklist for the Product Category display, within the selector, only the “regular” Name for each Product Category each time an information consumer executed the report. The only change, they tell us this time around, is within the Caption for the parameter picklist.

The client representatives tell us that they want the new Caption for the Product Category picklist to consist of a combination of the Product Category Key, a numeral that is familiar to many (particularly “old school”) Adventure Works information consumers, and the “regular” Name for their Product Categories. The new Caption, seen at report runtime, for the Product Category picklist will therefore be a concatenation of the Key and the Caption / Name (with a ““ separator) for the Product Category. An illustration would be a Caption for the Components Product Category, which would appear as “2 – Components”.

While the focus of our article is the MDX required to meet this request, and specifically upon the use of the MEMBER_KEY property within an MDX query, the dataset that this query generates would be added in Reporting Services’ Report Designer, among other steps, to meet the requirement for parameterization within the designated OLAP report. Let’s create a query to generate the needed picklist support elements, and then take a look at how we might use the data returned within the reporting layer.

Procedure: Use the MEMBER_KEY Property to Provide Parameter Picklist Support in Reporting Services

We again have a need that we can readily answer using the MEMBER_KEY property, in conjunction with the MEMBER_CAPTION property and a relative function, .CurrentMember. The solution also includes the .UniqueName function. We will be targeting the Caption column in the resulting dataset (we’ll call it Product Category – Full) for the name that is displayed in the selector of the parameter picklist. We will also include a simple Product Category – Key column, to illustrate the most basic use of the property, alongside the Product Category – Full column that it will support.

The Unique Name column of the returned dataset (the qualified “MDX” name for each Category member of the Product dimension, Product Categories attribute hierarchy), which we call Product Category – MDX Qual Name in the query we construct, will serve as the value that is actually passed to the cube in the MDX of the query. A benefit of being able to pass the MDX-qualified name to Analysis Services, while presenting the information consumers the “friendly” name combination at run time, is that we insulate them from the MDX altogether, while providing them ad hoc selection of a Product Category upon which to filter the report data.

Our first step is to construct a query to return the requested Product Category list, presenting the selector Captions and Unique Names, (as well as the “pure” expressions from which our concatenated caption is derived), in side-by-side columns. The corresponding Product Category members of the Product dimension (Product Categories attribute hierarchy) will inhabit the row axis, as we shall see.

Let’s construct a query, therefore, to return the requested Product Category information, presenting the concatenated Product Category – Full, Product Category – Key, Product Category – Caption and Product Category – MDX Qual Name in four, side-by-side columns, with the corresponding Product Category member names as rows.

-- MDX067-01  Using .MEMBER_KEY, MEMBER_CAPTION, .CurrrentMember 
--     and .UniqueName to generate a picklist selection
   [Measures].[Product Category - Key]
   '[Product].[Product Categories].CurrentMember.MEMBER_KEY'
   [Measures].[Product Category - Caption]
   '[Product].[Product Categories].CurrentMember.MEMBER_CAPTION'
   [Measures].[Product Category - FULL]
   'VBA!CStr([Product].[Product Categories].CurrentMember.MEMBER_KEY) + 
       " - " + [Product].[Product Categories].CurrentMember.MEMBER_CAPTION'
   [Measures].[Product Category - MDX Qual Name]
   '[Product].[Product Categories].CurrentMember.UNIQUENAME '
   { [Measures].[Product Category - Key], 
     [Measures].[Product Category - Caption], 
         [Measures].[Product Category - FULL],
       [Measures].[Product Category - MDX Qual Name]}  
     ON AXIS(0),
   {[Product].[Product Categories].[Category].MEMBERS}
     ON AXIS(1)
   [Adventure Works]  

The Query pane appears, with our input, as depicted in Illustration 1.

Illustration 1: Our Query in the Query Pane …

2.  Execute the query by clicking the Execute (!) button in the toolbar.

The Results pane is populated by Analysis Services, and the dataset shown in Illustration 2 appears.

Illustration 2: Results Dataset: Combined Use of MEMBER_KEY, MEMBER_NAME, .UniqueName and .CurrentMember

We see the Product Category - Full captions, the output of the Product Category - Full calculated member, populating the third data column. The associated components of the Product Category - Full calculated member, underlying Product Category – Key and Product Category – Caption, appear, respectively, in the two columns to its immediate left. Finally, Product Category – MDX Qual Name, which contains the qualified name that will be passed to Analysis Services upon selection of a given caption within the ultimate parameter picklist, lies to the far right. The Product Category members themselves occupy the row axis, as the client has requested.

The calculated member Product Category – Key employs the MEMBER_KEY property in the simplest manner. The expression underlying this calculated member is concatenated with that underlying the Product Category – Caption to produce the results delivered by Product Category - Full calculated member. (We employ the VBA CStr() function to convert the Product Category – Key output to a string, before concatenating it, via the “+” operator, with the string output of Product Category – Caption.)

In the expression underlying the Product Category – MDX Qual Name calculated member, we employ the .UniqueName function, in conjunction with the “relative” .CurrentMember function, to produce the MDX qualified name that our parameter picklist will pass in the ultimate runtime report to Analysis Services as a filter. Finally, the juxtaposition of the members (via the MDX .Members function) of the Product dimension, Product Categories hierarchy, and Category level in our row axis, as we can easily see from our practical example, results in a combination list of the captions / qualified names of the members that we specify in our row axis. (Similarly, if we had specified the Subcategory or Product levels of the Product Categories hierarchy in the row axis instead, we would have obtained a list of the members of those levels as a result). Intersecting the calculations with the members under consideration can, of course, be leveraged, in similar fashion, to produce sophisticated results within more elaborate structures and processes.

3.  Select File > Save As …, name the file MDX067-01, and place it in a meaningful location.

Our client colleagues express satisfaction with our initial solution, and state that it satisfactorily displays the new, concatenated captions of the Product Categories, alongside the respective qualified / unique names within Analysis Services. We suggest one more enhancement, however, as we realize that the dataset we have produced will ultimately appear within a parameter picklist in one or more reports: We suggest that we order the dataset by Product Category – Key to make it a bit more user-friendly for information consumers at runtime.

4.  Select File > Save As, name the file MDX067-02, and place it in a meaningful location.

5.  In the top line of the query (the first of two commented lines) modify “MDX067-01” to “MDX067-02”.

6.  At the end of the second commented line, change the wording “a picklist selection” to “an ORDERED picklist selection”.

The comment lines atop the query appear, with our changes, as depicted in Illustration 3.

Illustration 3: The Comment Lines with Our Modifications …

Next, let’s use the MDX Order() function to order our row axis by Product Category Key.

7.  Replace the current row axis specification, which currently appears as:

{[Product].[Product Categories].[Category].MEMBERS}
     ON AXIS(1)

With the following syntax:

ORDER({[Product].[Product Categories].[Category].MEMBERS},
       ( [Measures].[Product Category - Key]), ASC)

The affected portion of the query appears, with our modifications, as shown in Illustration 4.

Illustration 4: The Row Axis Specification with Our Modifications …

8.  Execute the query by clicking the Execute (!) button in the toolbar, once again.

The Results pane is populated by Analysis Services, and the dataset depicted in Illustration 5 appears.

Illustration 5: Results Dataset – Modified Query that Orders the Product Category Key

We see, within the red rectangle in Illustration 5, that the dataset is now ordered by Product Category – Key. This will support the same ordering in the ultimate parameter picklist, which should make selections easier for the ultimate information consumers.

NOTE: For more information about the MDX Order() function, please see Basic Set Functions: The Order() Function , another member of my MDX Essentials series at Database Journal.

9.  Select File > Save MDX067-02 to save our last modifications.

We will not take the steps, as part of the practice procedures within this article, to construct the picklist apparatus within the reporting layer. However, let’s take a look at one approach to assembling the parts in Reporting Services (or, similarly, in another OLAP reporting application). First, we would transfer the query to Reporting Services’ own Data tab to generate a dataset within the report under consideration. This query, together with the dataset it generates, would look something similar to that which is shown in Illustration 6.

Illustration 6: Query and Dataset in Reporting Services to Support a Parameter Picklist

NOTE: This is only one approach to creating the dataset – perhaps the more obvious of several. Another might be more optimal, depending upon the reporting environment under consideration. Other approaches, the components of which might occupy different layers of the Microsoft integrated business intelligence solution, might include installation of the calculated members at the cube level, and then calling (versus defining and building) them from the reporting layer.

For a step-by-step procedure that demonstrates the construction of such a cube-based solution to support a picklist in Reporting Services, see Create a Cube-Based Hierarchical Picklist in my MDX in Analysis Services series, or Parameterization from Analysis Services – Cascading Picklists in my MSSQL Server Reporting Services series here at Database Journal.

Once we have created the dataset, the next step is to add a parameter to the report. Inside the Report Parameter definition, we would reference the new dataset (in the example I created for my illustrations I named it ProductCategory), as shown, and then select Product Category - MDX Qual Name and Product Category - Full within the Value and Label fields respectively. Illustration 7 presents a view of the way all this would tie together in the Report Parameter dialog inside Reporting Services.

Illustration 7: Pulling It All Together inside the Report Parameter …

At this point all that remains is to return to the primary dataset underneath the report and to insert the parameter placeholder within an axis specification or a slicer, where it acts as a filter (there are examples of this, and all other steps, in the articles I have cited above). Executing the query then triggers the “prompting” action of the new Product Category parameter.

The selection list, displaying the new, concatenated Product Category name, is manifested in the parameter dropdown when we preview or execute the report, as depicted in Illustration 8.

Illustration 8: The Product Category Parameter Selector in Action …

And so we see that our query, using the MEMBER_KEY and MEMBER_NAME properties, and the .UniqueName function, in conjunction with the “relative” .CurrentMember function, among others, to present the Keys, Captions and Unique Names for the Product Categories in side-by-side columns, can be readily used to support a picklist for a parameter within the reporting layer of the business intelligence solution of our client. Having demonstrated the workings of the MEMBER_KEY property in this fashion has helped us to show our client colleagues that we have, within the current dataset query, established support for parameterization based upon underlying cube data.

Our client colleagues express satisfaction with the results, and confirm their understanding of the operation of the MEMBER_KEY property within the contexts we have presented in the practice exercises. We reiterate to the Reporting team that knowing “where to put the intelligence” within the various layers of the Microsoft integrated BI solution can mean centralized maintenance, highly tuned performance and more effective solutions, in general, for consumers throughout our organizations.

10.  Select File -> Exit to leave the SQL Server Management Studio, when ready.

Summary …

In this article, we introduced the MDX MEMBER_KEY property, which can be called upon in activities that range from generating simple lists to supporting parameters in the reporting layer, as well as more sophisticated uses. We introduced the function, commenting upon its operation and touching upon the datasets we can deliver using MEMBER_KEY.

We examined the syntax involved with MEMBER_KEY, and then undertook an illustrative practice exercise showing a business use for the function, generating a query that capitalized on its primary features. Our exercise consisted of an example that drew upon our earlier examination of the MEMBER_CAPTION property, and included the use of the two properties in conjunction with the MDX .UniqueName function, and the “relative” .CurrentMember function, among others, to present the Keys, Captions and Unique Names for the Product Categories in side-by-side columns within a results dataset. We then illustrated using such a dataset to support a parameter picklist in a report that queried an Analysis Services data source. Throughout our practice session, we briefly discussed the results we obtained from each of the steps we progressively completed.

» See All Articles by Columnist William E. Pearson, III

Discuss this article in the MSSQL Server 2000 Analysis Services and MDX Topics Forum.

Mobile Site | Full Site