
DSO Application Object Usage Effect
Object usage can be classified into three types:
-
Read operations, which look for the values of properties of the object.
-
Modification operations, which change the metadata in the repository.
-
Processing operations, which use the Process method of the object causing the service to process the object.
Note: |
|---|
|
In order for you to run the VBS script samples in the next sections, you must have a testing environment that includes databases from SQL Server 2000 Analysis Services that were migrated to SQL Server Analysis Services. The sample database FoodMart 2000 must be part of the SQL Server 2000 Analysis Services repository for some of the scripts to work. The testing environment must have at least one server that has SQL Server 2000 Analysis Services installed on it and one server that has SQL Server Analysis Services installed on it. DSO 8.5 must already be installed and must be set up on the server that is running SQL Server.
|
Reading an Object's Properties
All DSO read operations to any object's properties are resolved from the SQL Server 2000 Analysis Services repository and never use the SQL Server Analysis Services instance to obtain object properties.
A mixed environment in SQL Server Analysis Services with DSO enabled is defined as an environment in which there are SQL Server 2000 Analysis Services databases that have been migrated to SQL Server Analysis Services as well as other new databases that were created by using SQL Server Analysis Services. Then running a DSO application that lists all databases in a server will produce a list that contains all databases that are defined in the SQL Server 2000 Analysis Services repository, regardless of whether or not they have been migrated to SQL Server Analysis Services. However, the list will not contain any newly created SQL Server Analysis Services databases. You can try this by running the sample DSO_ListDB.vbs and comparing the produced log file against what you see in SQL Server Management Studio in SQL Server.
If repositories are the same on both the server that is running SQL Server and the server that is running SQL Server 2000, then the script produces the same results when it is run on both servers.
Creating, Modifying, or Dropping Objects
Using DSO to modify objects does not change them in SQL Server Analysis Services, it only changes them in the SQL Server 2000 Analysis Services repository. When your DSO application issues any command to change the structure of the existing objects in Analysis Services databases, that command connects to the SQL Server 2000 Analysis Services repository and changes the object in the repository, but the existing structure in the SQL Server Analysis Services instance is not modified.
For example, if you use DSO to create a new Sales cube in the FoodMart 2000 database and then read from the SQL Server 2000 Analysis Services repository, you will see the new cube there. However, when you review the existing objects in SQL Server Analysis Services by using SQL Server Management Studio, you will see no new Sales cube created, because nothing has been processed in DSO.
You can try this concept by first running the script DSOCreateNewSimplifiedSalesCube.vbs, then using SQL Server Management Studio to review the existing cubes in the FoodMart 2000 database on the SQL Server Analysis Services instance, You will not find the new Sales cube in it yet. However, if you read from the SQL Server 2000 Analysis Services repository running the DSOListDimensionsAndCubesProperties.vbs script, you will find that the new cube was created.
Processing Objects
The only moment that DSO 8.5 connects to SQL Server Analysis Services is when a process method from an object is invoked. At that time, the migration logic starts to work, reading the repository and using AMO to create objects in SQL Server Analysis Services. Next, the minimum required objects are processed, in order to process the object upon which the process method was invoked.
If you have been following the previous explanations and running the scripts, then by now you will have created the New Sales cube in the SQL Server 2000 Analysis Services repository, though it is not yet visible in SQL Server Analysis Services instance. If you have not followed the previous steps, you should go back to Creating, modifying or dropping objects and run the scripts described there.
Running the DSOProcessFull_NewSalesCube.vbs script executes a full process on the NewSales cube, which makes the NewSales cube visible to you in SQL Server Management Studio. If you use SQL Server Management Studio to look at the NewSales cube that was created by the script, it appears no different from any other cube that you created in SQL Server 2000 Analysis Services; it is just a regular cube with two shared dimensions. To understand how DSO is related to migration, drop the FoodMart 2000 database from SQL Server Analysis Services using SQL Server Management Studio and run again DSOProcessFull_NewSalesCube.vbs. After you run the script, you will find that all FoodMart 2000 has been migrated to SQL Server Analysis Services; only the customers and product dimensions, and the NewSales cube are processed. Now, compare the virtual cubes 'Warehouse and Sales' and 'Trained Cube' in SQL Server 2000 Analysis Services to the real cubes created in SQL Server Analysis Services.You can see that the cubes in SQL Server Analysis Services have linked measure groups defined rather than being virtual cubes, because virtual cubes no longer exist in SQL Server Analysis Services. Look for the location in SQL Server Analysis Services of the virtual dimensions 'Store Size in SQFT' and 'Store Type' from SQL Server 2000 Analysis Services. You will find that they were converted to hierarchies in the 'Store' dimension, to discover this you have either to process the 'Store' dimension using SQL Server Management Studio, or to script out the dimension as a create statement and review the XML for Analysis (XMLA) script.
As you have seen in the previous sample, every time that the process method of an object is invoked in a DSO application, the migration logic is used to create corresponding objects in SQL Server Analysis Services. For more information about the known considerations for migrating databases from SQL Server 2000 Analysis Services to SQL Server Analysis Services, see Breaking Changes to Analysis Services Features in SQL Server 2008, Behavior Changes to Analysis Services Features in SQL Server 2008, Discontinued Analysis Services Functionality in SQL Server 2008, and Deprecated Analysis Services Functionality in SQL Server 2008.