Considerations For Naming Decision Support Objects


  This feature will be removed in the next version of Microsoft SQL Server. Do not use this feature in new development work, and modify applications that currently use this feature as soon as possible.

When naming Decision Support Objects (DSO) objects, you should follow a consistent naming convention and ensure that the name of each object is unique. Most of the naming conventions supplied in this topic are optional; some are required, as in the cases of virtual and private dimensions. The following naming convention assists in understanding the sometimes complex hierarchies formed by the DSO object model; the use of unique DSO object names also speeds performance.

DSO Object Naming Requirements

When you create a DSO object in an application, you must set a value for the object's Name property to differentiate it from similar objects in use and/or stored on the Analysis server. To prevent errors during execution time caused by characters that are not valid, follow these guidelines when you name objects:

  • All names must begin with a letter, with the exception of virtual dimensions. The name of a virtual dimension must start with a tilde (~) character.

  • A dimension can contain a single period (.) in its name if it contains multiple hierarchies. This period serves to separate the dimension name from the hierarchy name. (For example, consider MyDim.Hier1 and MyDim.Hier2, where MyDim is a dimension with two hierarchies, named Hier1 and Hier2.) Private dimensions must contain the cube name followed by a caret (^) character and the dimension name.

  • Avoid most symbol characters. Some objects have specific limitations regarding nonalphanumeric characters, while other objects supply meaning to certain nonalphanumeric characters, such as the tilde (~) and caret (^) characters. The following table lists characters that are not allowed.

  • The following reserved names should not be used for DSO objects:

    • AUX

    • CLOCK$

    • COM1 through COM9 (COM1, COM2, COM3, and so on)

    • CON

    • LPT1 through LPT9 (LPT1, LPT2, LPT3, and so on)

    • NUL

    • PRN


Invalid characters


The name must follow the rules for Microsoft® Windows computer names. (IP addresses are not valid.)

Data source

: / \ * | ? " () [] {} <>


. , ; ' ` : / \ * | ? " & % $ ! - + = [] {}


, ; ' ` : / \ * | ? " & % $ ! - + = () [] {}

All other objects

. , ; ' ` : / \ * | ? " & % $ ! - + = () [] {}

The Importance of Unique Names

Object names in Multidimensional Expressions (MDX) queries are resolved in a specific order. For best results with cube speed and accuracy, make the effort to use unique names for all objects you create in a database on an Analysis server. If using unique names is not an option, make an effort to qualify names as completely as possible in your queries, especially in cases where identical names appear in different dimensions and levels. The following paragraphs outline the order in which name conflicts in MDX statements are resolved.

When matching names to cube objects in an MDX query, the Analysis server first tries to match the initial portion of the name to a dimension, then a level, and finally, a member. When the server is satisfied that it has located one of these objects, it then uses the final element in the name to search within the bound object. For example, suppose there is a dimension [D1], a level [L1], and a member [M]. The statement [D1].[L1].[M] is broken down and [D1].[L1] is bound to the level. The server then searches the level for the member [M].

If a level in a dimension has a name identical to another dimension that is not its parent, that level will not be searched by a poorly constructed query. For example, suppose there are two dimensions [D1] and [D2]. [D2] has a level named [D1]. If a query refers to a member as [D1].[M], the Analysis server binds the name [D1] to the dimension and searches for [M] there. If it cannot find [M] in [D1], the query fails (once the server has bound a name to an object, it does not continue to the next object in the collection if the search fails). For this type of query to succeed, it should include the complete hierarchy of the dimension to locate the member: [D2].[D1].[M].

The same rules apply to members with children. Suppose there is a dimension [D1] with both a level and a member named [L1]. The member [L1] also has a child [C]. In an attempt to reference [C], [D1].[L1].[C] fails because the server binds [D1].[L1] to the level and searches for [C] as a member. For this type of query to succeed, it should include the complete hierarchy of the dimension to locate the child: [D1].[L1].[L1].[C].

A first-fit algorithm solves ambiguities in member names. If a member is referred to as [M] (without a corresponding parent dimension), the server searches the dimensions in the order they are listed in the cube's Dimensions collection until it finds the member. Although this can help resolve ambiguous member names, this process is slow and can affect performance. If the member is located in two different levels of the same dimension, the server returns the member closest to the root of the dimension tree.