Provider Implementation Considerations for Unique Names

OLE DB Programmer's Reference

In general, there are two ways for a provider to generate a unique name:

• Use a qualified name. In this method, the unique name is qualified to the extent needed to make it unambiguous. For example, a member may be qualified by all of its ancestors all the way to the root, and the root itself may be qualified by the name of the hierarchy and the dimension.
• Use a unique string with no implied structure. In this method, the provider generates a unique name that is just a string with no internal structure. It could be a string that represents a hash table location, for instance.

Using a qualified name as a unique name can have performance advantages. Because the name encodes the "path" to a member, it decreases the search required to locate that member. The disadvantage is that if the name of an ancestor changes, the path becomes invalid. If the path becomes invalid, the queries stored in the application no longer work.

Using a unique string with no internal structure gets around this problem. However, because it no longer contains the path, the search time required to locate the member increases.

It is possible to create a method that has the advantages of both these approaches. For example, the provider can return a string that encodes the "location" information without tying that to the uniqueness of the name itself.

In addition, depending on your provider, the shortest unambiguous name may be the most optimal for object lookup. For example, the member name "Europe" may produce faster results than "Geography.Europe."

Note   OLE DB for OLAP does not impose any structure on the provider for uniqueness.

Provider writers should keep these considerations in mind when deciding on what to expose as a unique name.

Note   When an MDX statement contains ambiguous names, it is provider dependent whether it raises an error or uses default qualifiers to make the names unambiguous. For example, the name "October" in the expression "October.CHILDREN" is ambiguous because the year is not specified. A provider may either raise an error or return the children of "October" for the default year. If 1998 is the default year, the expression is equivalent to "1998.October.CHILDREN".

1998-2001 Microsoft Corporation. All rights reserved.