As a MicroStrategy developer, you are constantly using Object Manager to migrate objects that you develop inside the Subject Areas folder in your project. To save time, what object can you create to enable you to go straight to this folder when you open Object Manager?
B. Project Source
E. You cannot accomplish this in the Object Manager.
Opening multiple project sources at once in Object Manager
You may need to migrate objects between the same projects on multiple occasions. For example, you may need to move objects from your development environment to your test environment on a regular basis. Object Manager allows you to save the projects and project sources that you are logged in to as a layout. Later, instead of opening each project and project source individually, you can open the layout and automatically re-open those projects and project sources.
The default file extension for Object Manager Layout files is .omw.
To open an existing Object Manager layout
From the File menu, select Open Layout. The Select Layout dialog box opens.
Select a layout and click Open. A Login dialog box opens for each project source specified in the layout.
For each Login dialog box, type a MicroStrategy login ID and password. The login must have the Use Object Manager privilege.
Click OK. The project sources open. You are automatically logged in to the projects specified in the layout, as the user you logged into the project source with.
To save a workspace as an Object Manager layout
Log in to any project sources and projects that you want to save in the layout.
From the File menu, select Save Layout. The Save Layout dialog box opens.
Specify a location and name for the layout file and click Save. The layout is saved.
MicroStrategy Course Where You Will Learn About This Topic
MicroStrategy Administration: Application Management Course
With the release of MicroStrategy Analytics Enterprise 9.4.1, the Analytical Engine logic has been enhanced with respect to joining data from multiple datasets in a Report Services Document. One of the features that is available with this release is the ability to use objects (e.g., attributes, metrics) from multiple datasets in a single grid in a document.
If an attribute on a grid has elements that can be obtained from multiple datasets used in the document, the elements displayed will be from the global lookup table. Additionally, if one or more of the datasets containing the attribute has missing attribute form data or has different attribute form from the other datasets, the Analytical Engine will follow the rules noted below to compose the final output:
If there is attribute form with null value, the Analytical Engine will use the non-null form value from other datasets instead of the null form.
If several datasets have different attribute form information for the attribute element, the Analytical Engine will use the attribute form from the biggest dataset.
If several datasets have different attribute form information for the attribute element, and those datasets have same number of rows, the Analytical Engine will use the first dataset in the document for the attribute form value (according to the dataset adding sequence).
NOTE: Users should note that the rules are applied for each individual attribute element in the result at the row level rather than at the dataset level.
Users may consider the following datasets – C01 is a dataset with Customer City, Customer and Order:
C02 is a dataset with Customer, Order and a profit metric. Users may note that the Customer attribute is missing the DESC form in the second dataset:
If a Report Services Document is built with both these datasets, and the attributes are placed on a grid, the following results may be seen. As noted in Rule 1, the Analytical Engine will display the non-Null values from C01 for the Customer attribute elements:
Now users may consider a different dataset as C02 – similar to the initial dataset, but here the Customer name (DESC) form contains values instead of NULLs. This time the values for the attributes are not consistent – see that Customer ID ‘1’ has different values for the DESC form for different Orders (1 & 6).
|Customer Name||Customer ID||Order||Profit|
If a report is built for this dataset users will observe that the first attribute element value in the dataset is used as as the DESC form for the Orders 1 & 6 even if the value is different in subsequent rows (this is the same as previous Analytical Engine behavior).
When these datasets are used in the grid in a Report Services Document, the Analytical Engine will choose the attribute element values from dataset C02 to display in the attribute element values from. This is because of Rule 2 explained above.
Consider the following dataset:
|Customer Name||Customer ID||Order||Profit|
A report built off this dataset appears as follows:
After replacing the dataset ‘C02‘ from the previous example with the new dataset, the following results are seen. As noted in Rule 3, because both C01 an C02 have the same number of rows, the elements displayed for the Customer attribute will be filled from from the first dataset to be added to the document – in this case C01. However for the first row in the results, where there is no corresponding customer in the dataset C01, Rule 1 will be applied and instead of a NULL value, the non-null Customer Name field ‘Customer G’ is picked from C02. (Rules are applied at the individual element level).
Next: Why are some metric values blank in documents using multiple datasets in MicroStrategy Analytics Enterprise 9.4.1
 MicroStrategy Knowledgebase, Engine behavior for grids on a Report Services Document or dashboard with multiple datasets where some attribute forms are missing or have different values the datasets in MicroStrategy Analytics Enterprise 9.4.1 and newer releases, TN Key: 45463, 03/13/2014, https://resource.microstrategy.com/support/mainsearch.aspx.
NOTE: You may need to register to view MicroStrategy’s Knowledgebase.
Tips & Tricks #7: How to Enable or Disable Match Case Sensitivity for Prompts using MicroStrategy Web
Believe it or not, this is a question I get asked a lot by clients. Based on their requirements or data, many clients do not want the Match Case Sensitivity check box preference enabled to begin with when they are prompted. Fortunately for us, the solution to this is fairly simple as I show below.
If you have a MicroStrategy question you would like me to answer or blog about, please e-mail it to me (include screenshots if it will help) to firstname.lastname@example.org. I will do my best to answer your questions.
Match Case Sensitivity Preference
When you run certain prompt types in MicroStrategy Web, the interface offers a search option followed by a Match Case Sensitivity check box.
This functionality allows users to search for specific elements within the prompt’s available answers. To allow even more flexibility, the check box allows the user to restrict the search results only to those that match the case entered. In the screenshot below, you can see the check box is enabled (checked) and case sensitivity will be matched.
However, you can control whether this option is enabled or disabled by default for all prompts by setting the following preference in MicroStrategy Web.
This option is under Preferences, Project Defaults, Prompts.
Don’t forget to press the Apply button for the changes to take place.
Now, in the screenshot below, you can see the check box is disabled (unchecked) and case sensitivity will not be matched.