Compartilhar via

  • Artigo

Porting DSO to AMO

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 Analysis Services.

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 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 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, 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, 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 Mudando do DSO 8.0, Introdução às classes AMO, and Objetos de Gerenciamento de Análise (AMO).