AMO other classes and methods

Applies to: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

This section contains common classes that are not specific to OLAP or data mining, and that are helpful when administering or managing objects in Analysis Services. These classes cover features such as stored procedures, tracing, exceptions, and backup and restore.

The following illustration shows the relationship of the classes that are explained in this topic.

Assembly objects

An Assembly object is created by adding it to the assemblies collection of the server, and then updating the Assembly object to the server, by using the Update method.

To remove an Assembly object, it has to be dropped by using the Drop method of the Assembly object. Removing an Assembly object from the assemblies collection of the database does not drop the assembly, it only prevents you from seeing it in your application until the next time that you run your application.

For more information about methods and properties available, see Assembly in Microsoft.AnalysisServices .

Backup and restore methods

Backup and Restore are methods that can be used to create copies of a database and recover the database by using the copy. The Backup method belongs to the Database object, and the Restore method belongs to the Server object.

Only server and database administrators are permitted to perform a backup of a database. Only server administrators can restore a database onto a different server than it was backed up from. Database administrators can restore a database by overwriting the existing database only if they own the database that is to be overwritten. After a restore, the database administrator may lose access to the restored database if the database is restored with its original security definitions.

Database backup files must have .abf extensions.

Backup method

To backup a database, use the Backup method of the database object with the name of the backup file as a parameter.

Default values

AllowOverwrite=false

BackupRemotePartitions=false

Security=CopyAll

ApplyCompression=true

Restore method

To restore a database to a server, use the Restore method of the server with the backup file as a parameter.

Default values

AllowOverwrite=false

DataSourceType=Remote

Security=CopyAll

Restrictions

1. A local partition cannot be restored as a remote partition.

2. A remote partition cannot be restored as a local partition, but a remote partition be restored on a different server than it was backed up from.

Common parameters and properties for Backup and Restore methods

• File is the name of the file to backup (UNC name) into/from.

• Location specifies server-specific backup information, such as BackupFile.This allows you to specify a separate backup file for a remote database.

• DatasourceID specifies the ID of the subordinate database in a remote server.

• ConnectionString allows you to adjust the remote datasource in case the remote server has changed. DatasourceID must always be specified when ConnectionString is present.

• Folder allows remapping of the folders for partitions on the local hard drive

• Original is the original folder for local partitions.

• New is the new location for local partitions that used to reside in the corresponding 'Original' old folder.

• Password, if non-blank, specifies that the server will encrypt the backup file.

Trace objects

Trace is a framework used for monitoring, replaying, and managing an instance of Analysis Services. A client application, like SQL Profiler, subscribes to a trace and the server sends back trace events as specified in the trace definition.

Each event is described by an event class. The event class describes the type of event generated. Within an event class, event subclasses describe a finer level of categorization. Each event is described by a number of columns. The columns that describe a trace event are consistent for all events and conform to the SQL trace structure. Information recorded in each column may differ depending on the event class; that is, a predefined set of columns is defined for each trace, but the meaning of the column may differ depending on the event class. For example, the TextData column is used to record the original ASSL for all statement events.

A trace definition can include one or more event classes to be traced concurrently. For each event class, one or more data columns can be added to the trace definition, but not all trace columns must be used. The database administrator can decide which of the available columns to include in a trace. Further, event classes can be selectively traced based on filter criteria on any column in the trace.

Traces can be started and deleted. Multiple traces can be run at any one time. Trace events can be captured live or directed to a file for later analysis or replay. SQL Profiler is the tool used to analyze and replay trace events. Multiple connections are allowed to receive events from the same trace.

Traces can be divided in two groups: server traces and session traces. Server traces will inform of all events in the server; session traces will inform only events in the current session.

Traces, from the traces collection of the server, are defined the following way:

1. Create a Trace object and populate its basic data, including trace ID, name, log file name, append|overwrite, and others.

2. Add Events to be monitored to the Events collection of the trace object. For each event, data columns are added.

3. Set Filters to exclude unnecessary rows of data by adding them to the filters collection.

4. Start the trace; creating the trace does not start collecting data.

5. Stop the trace.

6. Review the trace file with SQL Profiler.

Traces, from the session object, are obtained in the following manner:

1. Define functions to handle the trace events generated in your application by SessionTrace. Possible events are OnEvent and Stopped.

2. Add your defined functions to the event handler.

3. Start the session trace.

4. Do your process and let your function handlers capture the events.

5. Stop the session trace.

6. Continue with your application.

CaptureLog class and CaptureXML attribute

All actions to be executed by AMO are sent to the server as XMLA messages. AMO provides the means to capture all these messages without the SOAP headers. For more information, see Introducing AMO Classes. CaptureLog is the mechanism in AMO for scripting out objects and operations; objects and operations will be scripted in XMLA.

To start capturing the XML, the CaptureXML server object property needs to be set to true. Then all actions that are to be sent to the server will start being captured in the CaptureLog class, without the actions being sent to the server. CaptureLog is considered a class because it has a method, Clear, which is used to clear the capture log.

To read the log, you get the strings collection and start iterating over the strings. Also, you can concatenate all logs into a string by using the server object method ConcatenateCaptureLog. ConcatenateCaptureLog requires has three parameters, two of which are required. The required parameters are transactional, of Boolean type, and parallel, of Boolean type. If transactional is set to true, it indicates that the XML batch file will be created as a single transaction instead of each command being treated as a separated transaction. If parallel is set to true, it indicates that all commands in the batch file will be recorded for concurrent execution instead of sequentially as they were recorded.

AMOException exception class

You can use AMOException exception class to easily catch exceptions in your application that are thrown by AMO.

AMO will throw exceptions at different problems found. The following table lists the kind of exceptions that are handled by AMO. Exceptions are derived from the AmoException class.