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.
In Decision Support Objects (DSO) there are two ways to classify objects: objects that can be accessed and managed directly, and objects that implement a DSO interface.
Objects that can be accessed and managed directly have their own collections, methods and properties. They include the following classes:
Class type designations that use the format clsClassType, such as clsServer, are used internally by the DSO ClassType property and do not necessarily correspond to a particular class definition within Microsoft® Visual Basic®.
Objects that implement an interface use a subset of the collections, methods, and properties associated with the interface. The DSO ClassType and SubClassType properties determine which features of an interface are implemented by a particular object. Information about these features appears throughout this document.
Each collection, method, and property description contains the names of the objects in which it appears. Conversely, each object description contains the names of the collections, methods, and properties that the object implements.
The following table lists the six DSO interfaces and the objects that implement them.
For more information, see Interfaces.
The DSO object model uses interfaces to simplify your interaction with groups of related objects, while maintaining parent-child inheritance throughout the object model hierarchy. For more information about the complete hierarchy, see Introducing Decision Support Objects.
Each DSO object that implements a DSO interface belongs to one of the following categories:
The uniqueness of multiple DSO objects within the same category is determined by where each is contained within the overall DSO object model hierarchy. For example, a cube can contain several dimensions. These dimension objects are contained in the Dimensions collection of the cube. Each of these dimension objects is a DSO object of ClassType clsCubeDimension.
Each cube also contains a collection of partition objects. Each of these partition objects also contains a collection of dimension objects in its Dimensions collection. Each of these dimension objects is a DSO object of ClassType clsPartitionDimension.
Although the DSO objects of ClassType clsCubeDimension and clsPartitionDimension are both dimension objects, their methods and properties are unique because of the parent objects in which their collections are contained. The DSO object model groups such objects together and manages them by the implementation of a common interface.
In DSO, most child objects cannot commit their own changes to the Analysis server, but instead must rely on their parent object to commit the changes of their child objects. Any object that can commit itself and its children is referred to in DSO terminology as a major object. Any object that cannot commit itself, but must rely on a major object to perform such an action, is referred to as a minor object.
Objects with the following ClassType property values are considered major objects:
All objects not included in the previous list are considered minor objects. To commit changes to major and minor objects, all major objects in DSO support the Update method. Any change to a DSO minor object must be committed through the parent DSO major object in order to be committed. For example, a change to a clsCubeRole object is committed only when the Update method of its parent clsCube object is executed. Although most interfaces in the DSO hierarchy have an Update method, attempting to use the Update method on a minor object in DSO will result in an error.