The LEVEL_NUMBER Member Property

This month, we will examine the LEVEL_NUMBER intrinsic member property. Once we have briefly introduced LEVEL_NUMBER, we will employ the member property, in a hands-on practice session, to meet example business needs for a hypothetical client. The primary focus of this article, like the other articles of this series, is to provide hands-on application of the fundamentals of the Multidimensional Expressions (MDX) language, doing so here specifically within the context of the LEVEL_NUMBER intrinsic member property, in combination with other member properties and MDX functions.

Note: For more information about my MDX Essentials column in general, see the section entitled “About the MDX Essentials Series” that follows the conclusion of this article.


In this lesson, we will examine another intrinsic member property, LEVEL_NUMBER. As many of us are aware, 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. LEVEL_NUMBER belongs to the latter group of properties. As a general group, intrinsic member properties provide additional information that can be used by applications to enhance the ultimate user experience. Support for the non-context sensitive member properties is the same for all members, regardless of individual context.

The purpose of the LEVEL_NUMBER property is to support the return of the numerical “distance” of a given member from the root of the hierarchy to which the member belongs. LEVEL_NUMBER can be useful in a host of different applications. Moreover, as I have noted to be the case for other functions and properties within the MDX Essentials series, LEVEL_NUMBER 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 LEVEL_NUMBER property can be leveraged in activities that range from generating simple lists to supporting sophisticated presentations. It can be a particularly effective tool when we need to provide parameter picklist support 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 shall:

  • 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.



According to the Analysis Services Books Online, the LEVEL_NUMBER property specifies “the distance of the member from the root of the hierarchy.” In Analysis Services, the root level is zero. LEVEL_NUMBER has many applications, including the rather obvious uses with Analysis Services members that are included in the basic definition, as well as its pairing with other MDX functions to leverage its power even further. As an example, as we have seen is the case with many other member properties and functions in earlier articles of this series, LEVEL_NUMBER can also be synergistically combined with the .CurrentMember function; we will see an example of this specific combination within the practice exercises that follow.

We will examine the syntax involved in leveraging the LEVEL_NUMBER property after our customary overview in the Discussion section that follows. Having completed the introduction, we will conduct practice examples within a couple of scenarios, constructed to support hypothetical business needs that illustrate uses for the property. This will afford us an opportunity to explore some of the presentation options that LEVEL_NUMBER can offer the knowledgeable user. Hands-on practice with LEVEL_NUMBER, 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 LEVEL_NUMBER property, when acting upon a member, returns the number (again, with the root level of the containing hierarchy being zero) of the level to which the object – to which it is appended with the period (“.”) delimiter – belongs. LEVEL_NUMBER 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 LEVEL_NUMBER 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 function, residing 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 scenarios. For more of my observations on this subject, see Multi-Layered Business Intelligence Solutions … Require Multi-Layered Architects.

The LEVEL_NUMBER property returns, as we have noted, the hierarchical level number within which the specified member is contained, and can be used for querying and display, among other, purposes.

Let’s discuss syntax considerations to further clarify the operation of LEVEL_NUMBER.


Syntactically, anytime we employ the LEVEL_NUMBER property to return the associated level number, the member for which we seek to return the level number is specified to the left of LEVEL_NUMBER. The property takes the object to which it is appended as its argument, and returns, within a string, the unique level name to which the specified object belongs. The general syntax is shown in the following string:


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

As is typically the case with the majority of MDX functions, operators and properties, the LEVEL_NUMBER 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 LEVEL_NUMBER property in the section that follows.

William Pearson
William Pearson
Bill has been working with computers since before becoming a "big eight" CPA, after which he carried his growing information systems knowledge into management accounting, internal auditing, and various capacities of controllership. Bill entered the world of databases and financial systems when he became a consultant for CODA-Financials, a U.K. - based software company that hired only CPA's as application consultants to implement and maintain its integrated financial database - one of the most conceptually powerful, even in his current assessment, to have emerged. At CODA Bill deployed financial databases and business intelligence systems for many global clients. Working with SQL Server, Oracle, Sybase and Informix, and focusing on MSSQL Server, Bill created Island Technologies Inc. in 1997, and has developed a large and diverse customer base over the years since. Bill's background as a CPA, Internal Auditor and Management Accountant enable him to provide value to clients as a liaison between Accounting / Finance and Information Services. Moreover, as a Certified Information Technology Professional (CITP) - a Certified Public Accountant recognized for his or her unique ability to provide business insight by leveraging knowledge of information relationships and supporting technologies - Bill offers his clients the CPA's perspective and ability to understand the complicated business implications and risks associated with technology. From this perspective, he helps them to effectively manage information while ensuring the data's reliability, security, accessibility and relevance. Bill has implemented enterprise business intelligence systems over the years for many Fortune 500 companies, focusing his practice (since the advent of MSSQL Server 2000) upon the integrated Microsoft business intelligence solution. He leverages his years of experience with other enterprise OLAP and reporting applications (Cognos, Business Objects, Crystal, and others) in regular conversions of these once-dominant applications to the Microsoft BI stack. Bill believes it is easier to teach technical skills to people with non-technical training than vice-versa, and he constantly seeks ways to graft new technology into the Accounting and Finance arenas. Bill was awarded Microsoft SQL Server MVP in 2009. Hobbies include advanced literature studies and occasional lectures, with recent concentration upon the works of William Faulkner, Henry James, Marcel Proust, James Joyce, Honoré de Balzac, and Charles Dickens. Other long-time interests have included the exploration of generative music sourced from database architecture.

Get the Free Newsletter!

Subscribe to Cloud Insider for top news, trends & analysis

Latest Articles