Porting DSO to AMO

Nouveau : 14 avril 2006

This topic is to explain to Decision Support Objects (DSO) developers the steps that are required to port existing legacy DSO applications to Analysis Management Objects (AMO), the new object model for programmatically administering Microsoft SQL Server 2005 Analysis Services (SSAS).

This topic is intended for OLAP database administrators and OLAP developers with experience developing and administering SQL Server 2000 Analysis Services applications and databases.

SQL Server 2000 was designed under COM object concepts including the DSO object model. In contrast, SQL Server 2005 was designed and built under .NET managed code concept therefore the new management object model, AMO, is to be used from managed code only. Nevertheless, both object models are very similar it is easy to move from DSO to AMO.

Most DSO applications are created in one of following ways:

• As compiled COM applications, in any language such as Visual Basic 6 or similar.
• As Windows Hosting Scripts (WHS), in Visual Basic script or jscript.
• As SQL Server 2000 DTS packages using ActiveX Scripting tasks.

Compiled DSO applications are mostly ported to compiled managed code applications by using AMO. Language selection is the choice of the developer; all languages are equally suited to work with AMO.

DTS packages that are using DSO inside ActiveX Script Tasks can be ported to Integration Services packages by using Script Task object with Visual Basic .Net and AMO. DTS packages that were built using Analysis Services Processing Task will have to be ported to SQL Server 2000 Integration Services using new Analysis Services Processing Tasks.

Applications developed under WHS will have to be ported to either a managed application or to a SQL Server 2005 Integration Services package using Script Task object with Visual Basic .Net and AMO.

Connecting to the Server

Connecting to a server is the same action on both environments. Both models start with the server as the topmost object in the hierarchy, and both models have a connect method that requires the server name as a string parameter. In AMO, the server name can be an instance name written in the format <ServerName>\<InstanceName>.

The following table shows the connect method on both object models.

DSO (vbs code)	AMO (C# code)	AMO (Visual Basic .NET code)
dsoServer.Connect "SS2000_Server"	amoServer.Connect("SS2005_Server");	amoServer.Connect("SS2005_Server")

Managing Objects

Managing objects in AMO is similar to DSO, because both object models are disconnected models from the server. Disconnected model mean that actions taken in the application are not reflected in server until they are committed. To commit actions, both object models use the method Update on the object being changed or the on the nearest parent object.

Creating Objects

Creating objects is very similar on both models. On each model, a new object is created by adding it to an object collection using the Add method from the object collection.

In DSO, most actions are executed using the MDStores interface instead of the object class. In AMO, actions are executed using the object class directly.

See the following examples.

DSO (vbs)	AMO (C#)	AMO (Visual Basic .NET)
set dsoDB = dsoServer.MDStores.AddNew("NewDb") dsoServer.Update	amoDB = amoServer.Databases.Add("NewDb"); amoDB.Update();	amoDB = amoServer.Databases.Add("NewDb") amoDB.Update()
Set dsoCube = dsoDB.MDStores.AddNew("NewCube") dsoDB.Update	amoCube = amoDB.Cubes.Add("NewCube"); amoCube.Update()	amoCube = amoDB.Cubes.Add("NewCube") amoCube.Update()
Set dsoMeasure = dsoCube.Measures.AddNew("NewMeasure") dsoCube.Update	//in SQL Server 2005, Analysis Services cubes can have more than 1 measure group. A measure group was required before adding the measure amoMG = amoCube.MeasureGroups.Add("NewMeasureGroup"); amoMeas = amoMG.Measures.Add("NewMeasure"); amoMG.Update()	'in SQL Server 2005, Analysis Services cubes can have more than 1 measure group. A measure group was required before adding the measure amoMG = amoCube.MeasureGroups.Add("NewMeasureGroup") amoMeas = amoMG.Measures.Add("NewMeasure") amoMG.Update()

Removing Objects

In DSO, all objects are removed from their corresponding collection and an update on the nearest parent object is necessary to complete the object removal. In AMO, objects can drop themselves and be removed from the server in one step, no update is necessary.

DSO (vbs)	AMO (C#)	AMO (Visual Basic .NET)
'Remove FoodMart 2000 database dsoServer.MDStores.Remove("FoodMart 2000") dsoServer.Update	//being amoDB a database object //the database pointed by amoDB is dropped from system amoDB.Drop();	'being amoDB a database object 'the database pointed by amoDB is dropped from system amoDB.Drop()
'Remove NewSales cube dsoDB.MDStores.Remove("NewSales") dsoDB.Update	//being amoCube a cube object //the cube pointed by amoCube is dropped from system amoCube.Drop();	'being amoCube a cube object 'the cube pointed by amoCube is dropped from system amoCube.Drop()

Changing Objects

Changing objects in DSO and AMO is similar, you modify properties on the object and at the end an Update method is issued to save all changes on the server.

DSO (vbs)	AMO (C#)	AMO (Visual Basic .NET)
' Start cube definition ' Set Description for new cube dsoCube.Description = "simplified sales cube" ' Provide the data source for the cube. dsoCube.DataSources.AddNew dsoDB.DataSources("FoodMart").Name ' Update cube to save changes dsoCube.Update	//Start cube definition //Set Description for new cube amoCube.Description = "simplified sales cube"; //Provide the data source for the cube. amoCube.Source = new DataSourceViewBinding("FoodMart"); //Update cube to save changes amoCube.Update();	' Start cube definition ' Set Description for new cube amoCube.Description = "simplified sales cube" ' Provide the data source for the cube. amoCube.Source = new DataSourceViewBinding("FoodMart") ' Update cube to save changes amoCube.Update()

Processing Objects

Processing the objects in both models is similar because on either model a Process() method is issued from the object that requires processing or from one of its ancestors. If the Process() method is issued on one of the ancestors, then the processing on the object is bound to the default value for processing the object defined on the ancestor.

DSO (vbs)	AMO (C#)	AMO (Visual Basic .NET)
' Default processing for all objects in a database dsoDB.Process	//Default processing for all objects in a database dsoDB.Process( ProcessType.ProcessDefault);	//Default processing for all objects in a database dsoDB.Process(( ProcessType.ProcessDefault)
' Full processing a cube dsoCube.Process 1 ' 1 = FullProcess	//Full processing a cube amoCube.Process( ProcessType.ProcessFull);	' Full processing a cube amoCube.Process( ProcessType.ProcessFull)

Summary

Porting DSO code into AMO code is straightforward. Both object models are very close to one another, which makes the transition process easier.

It is recommended that you learn the new options in AMO for updating and processing objects that do not exist in DSO. It is also recommended that you learn how to use DataSourceView objects in AMO, because those are now the source objects for most AMO objects. For more information, see Introducing AMO Concepts, Introducing AMO Classes, and Programming Administrative Tasks with AMO.

Voir aussi

Tâches

How to: Set Up DSO in Analysis Services

Concepts

Setting Up Decision Support Objects (DSO) in Analysis Services

Autres ressources

Introducing AMO Concepts
Introducing AMO Classes
Programming Administrative Tasks with AMO
Considérations relatives à la migration (SSAS)
Migration de bases de données Analysis Services existantes
Problèmes de mise à niveau connus pour SQL Server 2005 Analysis Services
Changements de comportement des fonctionnalités Analysis Services de SQL Server 2005
Fonctionnalités Analysis Services abandonnées dans SQL Server 2005
Fonctionnalités d'Analysis Services désapprouvées dans SQL Server 2005

Aide et Informations

Assistance sur SQL Server 2005