Tag Archives: Tips

Tips & Tricks # 14: How Attribute Roles Work in MicroStrategy


Attribute Roles

The support of attribute roles is among the most requested features in the schema/modeling area. It is the result of a common modeling practice where two or more attributes are defined using the same lookup table and column. When these attributes are placed on the same report, the result may return no data. To address this issue, a unique table name alias is required.
This Tips & Tricks post demonstrates a business scenario where two possible solutions are available in MicroStrategy:
  1. Explicit logical table aliasing can be used to generate correct report Structured Query Language (SQL).
  2. MicroStrategy SQL Generation Engine automatically detects tables where the same column is used to create two different attributes.

Business Case Scenario

The Airport Example

A user defines two attributes that have the same definition but play different roles in the business model. In this example, attribute Origin Airport and Destination Airport are defined using the same Lookup Table and Column (Airport_ID).


Both attributes share the same forms, or information about them (Description, Location, etc.). In the fact table, however, a separate column exists for each of their roles (Origin_Airport_ID and Destination_Airport_ID).


If the user places both attributes on a report to obtain the number of flights originated from ‘MIA’ and arrived at ‘LGA’, an empty result set is returned. The SQL statement tries to obtain the description of an airport that is both ‘MIA’ and ‘LGA’ at the same time (Airport_ID = “MIA” AND Airport_ID = “LGA”), thus generating an empty result set as shown below:


NOTE: The SQL for this template is similar to the following:


Returning no data as explained previously:



1. Explicit Table Alias Definition

The recommended way to model attribute roles in MicroStrategy is using explicit table aliases. This approach gives project architects direct control over the specific attributes to be treated as different roles, as well as their mappings to logical tables. This level of control can ensure consistent Engine behavior.

  1. In MicroStrategy Desktop Schema Objects/Tables folder, right-click on the Table and select ‘Create Table Alias’.


  2. A logical table alias is created for LU_AIRPORT as LU_AIRPORT (1). The alias name can be modified. In this example, the alias table is named ‘LU_AIRPORT_ALIAS’.
The two attributes, Origin Airport and Destination Airport, can each have its own lookup table.
In this example, the Destination Airport attribute uses LU_AIRPORT_ALIAS as the primary lookup table. Be sure to uncheck LU_AIRPORT as a source table so no join will be made.
Form Definition for the ID

Form Definition for the DESC


The Origin Airport attribute’s definition remains the same, using LU_AIRPORT as the source table for both of its forms. LU_AIRPORT_ALIAS is not checked as a source table.
Form Definition for the ID


Form Definition for the DESC


Report SQL


2. Automatic Attribute Role Recognition

A VLDB property is available at database instance level in the Query Optimizations folder, called “Engine Attribute Role Options.” The option is disabled by default. When enabled, the engine detects columns that support more than one attribute in the same table and automatically creates a separate alias in memory only for each attribute. These automatic aliases are not saved into the metadata and cannot be edited in MicroStrategy Desktop. Thus, while the engine attribute role option makes it more convenient to use attribute roles, it also represents a loss of control over the schema representation that is ultimately used for SQL generation. As a result, some logical schema designs may function incorrectly when using automatic role recognition.




Enabling/Disabling ‘Automatic Attribute Role Recognition’

Attributes are considered candidates for the unique table name alias feature if their attribute forms are defined off the same column of a lookup table. Due to the specific nature of the modeling design described above, and that users may want to create two attributes of the same definition, automatic attribute role recognition is an optional setting.

The Very Large Database (VLDB) ‘Engine Attribute Role Options’ property can be found under Project Configuration/VLDB Properties/Query Optimizations folder in the VLDB Settings.


1. Attribute roles are intended for lookup tables. Since automatic role recognition effectively splits a logical table into several virtual logical tables, the option should not be applied when a fact table supports more than one attribute on the same column. In that case, some levels of analysis will not be available (that is, reports may return the “Fact does not exist at a level that can support the requested analysis” error). In general there should be no need to have attribute roles on fact tables. However, if it is necessary in a specific scenario, explicit table aliases should be used.
2. The automatic detection option will not work if the attributes in the roles situation are in the same hierarchy, meaning that a child attribute is shared. In the example above, the two airport attributes do not have a common child attribute.
Source: Jaime Perez, TN6197: How do Attribute Roles Work in MicroStrategy 8.x?, MicroStrategy Knowledgebase, ‎08-30-2001.

Tips & Tricks #13: Star Schema in MicroStrategy

Star Schema 1

A Star Schema is a design that contains only one lookup table for each hierarchy in the data model instead of having separate lookup tables for each attribute. With only a single lookup table for each hierarchy, the IDs and descriptions of all attributes in the hierarchy are stored in the same table. This type of structure involves a great degree of redundancy. As such, star schema are always completely denormalized. Let’s review the star schema above based on the MicroStrategy Tutorial data model.

The schema contains only two lookup tables, one for each hierarchy. LU_LOCATION stores the data for all of the attributes in the Location hierarchy, while LU_CUSTOMER stores the data for all of the attributes in the Customer hierarchy. As a result, star schemas contain very few lookup tables-one for each hierarchy present in the data model. Each lookup table contains the IDs and descriptions (if they exist) for all of the attribute levels in the hierarchy.

Even though you have fewer tables in a star schema than a snowflake, the tables can be much larger because each one stores all of the information for an entire hierarchy. When you need to query information from the fact table and join it to information in the lookup tables, only a single join is necessary in the SQL to achieve the desired result.

Joins in a Star Schema

As an example, if you run the same report to display customer state sales, only one join between the lookup and fact table is required to obtain the result set as illustrated below.

Star Schema 2

To join the Customer State description (Cust_State_Desc) to the Sales metric (calculated from Sales_Amt) requires only one join between tables since the Customer State ID and description are both stored in the LU_CUSTOMER table. As a result, the query has to access only one lookup table to obtain all of the necessary information for the report.

Even though achieving this result set requires only a single join, star schemas do not necessarily equate to better performance. Depending on the volume of data in any one hierarchy, you may be joining a very large lookup table to a very large fact table. In such cases, more joins between smaller tables can yield better performance.

Characteristics of a Star Schema

The following is a list of characteristics of a star schema.

  • Contains fewer tables (one per hierarchy)
  • Contains very large tables (much larger than some forms of snowflake schemas due to storing all attribute ID and description columns)
  • Store the IDs and descriptions of all the attributes in a hierarchy in a single table
  • Requires only a single join when querying fact data regardless of the attribute level at which you are querying data


Source: MicroStrategy University, MicroStrategy Advanced Data Warehousing, Course Guide, Version: ADVDW-931-Sep13-CG.

Tips & Tricks #12: How to Troubleshoot Cross Joins in SQL Reports for the SQL Generation Engine 9.x

MicroStrategy Community Banner


In my last blog post, I blogged about the new MicroStrategy Community. Jaime Perez, VP of Worldwide Customer Services, and his crew have come up with a better way for us to engage with MicroStrategy as well as his team.

Speaking of Jaime, last June, he posted this great tip on the MicroStrategy Knowledgebase site as a TechNote. I am reblogging it since it is one of the most frequent questions I get asked and I find it an extremely useful Tip & Trick. Also, this will give you an idea of the great stuff being posted in the MicroStrategy Community.

Best Regards,


MicroStrategy and Cross Joins

In some scenarios, one may encounter cross joins in the SQL View of a standard, SQL Report in MicroStrategy.  Cross joins appear when two tables do not have any common key attributes between them in which they can inner join.  As a result, the two tables essentially combine together to create one table that has all the data from both tables, but this results in poorer performance with a common effect of increased execution times.  Sometimes these execution times, and performance hits, can be very severe.  Therefore, it is important to understand some simple steps that can be performed to resolve a cross join, as well as some steps to understand why it may be appearing in the SQL View of the report.

One common occurrence of a cross join is when a report contains at least two unrelated attributes in the grid, and no metrics are present in order to relate the unrelated attributes via a fact table.  Such a occurrence can be resolved in a few ways:

  1. Create a relationship filter, set the output level as the unrelated attributes (or the entire report level), and then relate these by a Logical Table object
  2. Create a relationship filter, set the output level as the unrelated attributes (or the entire report level), and then relate these by a Fact object
  3. Add a metric to the report that uses a fact from a table in which both attributes can inner join to

This provides a pathway from the fact table to the lookup tables in which the unrelated attributes are sourced from.  The result is an inner join between the fact table and the lookup tables, which resolves the cross join between the two unrelated lookup tables.

Options 1 and 2 provide a means in which the report template can remain as only attributes, whereas Option 3 would have a metric on the report.  Option 3 may not be desired if a metric does not want to be placed on the report.  Keep in mind that other techniques can also be employed to have the metric on the report, but formatted to be hidden from display.

More common scenarios include cross joins between a fact table and a lookup table, and are typically surprising to a developer.  These situations can be a bit more tricky to troubleshoot and resolve, but here are a few techniques that can be employed to try to resolve the issue:

  1. In SQL View look at where the cross join appears, and between which tables the cross join appears
  2. Open up those tables in the Table Editor by navigating to the Schema Objects\Tables folder, and double-clicking the tables
  3. Select the Logical View Tab of both tables to see all the logical objects mapped to the table
  4. Take note of which attributes have a key icon beside them
  5. These key attributes denote attributes at the lowest level of their hierarchy presently mapped to the table and/or attributes that are in their own hierarchy (meaning they have no parents or children)
  6. The SQL Engine will join 2 tables on common key attributes only, so if none of the key attributes on either table exist on both tables, then a cross join should appear

This means that just because a Region attribute exists on Table_A and a Region attribute exists on Table_B does not necessarily mean that the SQL Engine will join on Region.  If Region has its child attribute on the table, then that attribute should be the key as it is the lowest level attribute of its particular hierarchy mapped to the table.  If Region exists on both tables, and is also a key attribute on both tables, then an inner join should take place on Region.

This essentially means that one can find a cross join, investigate the tables in which it appears, and verify if at least 1 common key attribute exists between the tables.  If not, then that should be the first path to investigate because a cross join is correct in that scenario.


You can find a detailed video on how this issue is reproduced and resolved here: Tech Note 71019 . Steps to reproduce and resolve


MicroStrategy Technical Support can assist with resolving cross joins in a specific report, however caution should be taken when resolving such issues.  In some scenarios, the cross join is resolved through modifications to the schema objects, which can have a ripple effect to all other reports in an environment.  For example, if a relationship is changed in the Region attribute to resolve a cross join in one report, this change will be reflected in all other reports that use Region, and potentially the hierarchy in which Region belongs.  As a result, the SQL View of one report will have the cross join resolved, but the SQL may have changed in other reports using Region or its related attributes.  This may or may not be desired.  MicroStrategy Technical Support may not be able to fully understand the impact of such a schema change to the data model, so before a change is made to the data model the consequences of such a change should be fully understood by the developer, and any changes made to the schema should be recorded.


[1] Jaime Perez, TN47356: How to troubleshoot cross joins in SQL Reports for the SQL Generation Engine 9.x, MicroStrategy Community, 06/24/2014, http://community.microstrategy.com/t5/Architect/TN47356-How-to-troubleshoot-cross-joins-in-SQL-Reports-for-the/ta-p/196989.

[2] MicroStrrategy Knowledgebase, Tech Note 71019 . Steps to reproduce and resolve,

Tips & Tricks #11: The URL path is not visible in the report properties dialog box in MicroStrategy Web

The Issue

Each report and document has a URL path that could be used to directly execute the object when pasted in the browser address bar. The URL path can be found in the properties section when a user right-clicks on the object.

The expected view of that window is as follows:

The view observed by some users without the link feature:

The Cause

The required feature is not enabled in the MicroStrategy Web Admin page.

The Fix

  1. Navigate to the MicroStrategy Web Admin page.
  2. Select ‘Security’ on the left-hand side.
  3. Under ‘URL’, enable the feature – “Session information is included on the URL”.



If the session information setting should remain off for security reasons, use the Show Link feature as shown below.



MicroStrategy Knowledgebase Technical Note 39787, Updated July 22, 2013.

Tips & Tricks #10: How to Remove the Underlining from Hyperlinks Created on an Attribute or Metric

This is another one of those little tricks that can save you from pulling your hair out trying to figure it out.

By default, hyperlinks in a Report Services document are underlined. The underlining can not be removed by changing the format of the attribute or metric.

Tip 10-1

There is an Enhancement Request open with MicroStrategy on this, but MicroStrategy does currently provide a workaround.

Workaround to Remove the Underlining is to Clear the Default Link

Step 1: Right click the object that is linked and choose Edit Links.

Step 2: Click the Clear Default button while the link is highlighted.

Tip 10-2


Step 3: The underlining should now be removed as shown below.

Tip 10-3

CAVEAT: The only limitation to this workaround is that in order to now get to the link, the object has to be right clicked on. The user can not directly click on the object and be taken directly to the new page (see screenshot below).

Tip 10-4

Tips & Tricks #9: How Do Changes on the Source Report (Dataset) Get Reflected in MicroStrategy Report Services 9.x Documents

In MicroStrategy Report Services Documents, document datasets and their original source reports  (such as a grid report being used as a dataset) are not completely connected to each other. Depending on the changes made on the source report, it can be reflected differently on the document. Basically, the change can be divided into two types.

Type 1 – Formatting Changes

Formatting changes, for example, changing autostyles, thresholds, subtotals.

If a user chooses the option Add to Section without Formatting, the grid/graph showing on the document will not use the report’s stored formatting. Any formatting changes on the source report will not be reflected on the document.

Tip 9-1If a user chooses the option Add to Section with Formatting, the grid will be added with the current format of the report.  However, any formatting changes made to the source report AFTER the dataset has been included in the document will NOT be reflected on the document.

For example, a user disabled the subtotal (see screenshot below) for the original report after the report has been included as a dataset in a document, the document will still show the subtotals.

Tip 9-2

To force the document to recognize the report’s formatting changes, the user needs to delete the grid/graph from document section and add it again using the With Formatting option. By doing this, the latest formatting properties of the grid/graph on the source report are retrieved.

Type 2 – Adding/Removing Objects and Modifying Report Filters

Another type of changes made on the report involving adding/removing objects and modifying report filters.

Unlike the formatting change, this type of change does carry over from the source report to the document datasets.

For example, if users add/remove/modify report filters (see screenshot below), the change will be reflected on the data when running the document.

Tip 9-3

If an object is removed from the source report (see screenshot below), the user can see the change in the document’s Dataset Objects window. After the user runs the document, the object will be removed from grid/graph on the document.

Tip 9-4

If an object is added to the report (see screenshot below), the change will show in the document’s dataset objects window. However, the object will not be automatically added to the grid/graph. The user has to manually add the object to the grid/graph or add the dataset to the section again to make it show up.

Tip 9-5

NOTE:   As of MicroStrategy 9.0, a new feature was introduced where a user can add a dataset report to a Report Services document as a shortcut by selecting the Add to Section As a shortcut option, as shown below:

Tip 9-6

If the grid/graph is added to the document using this option, then the document would be updated automatically if ANY type of change is made on the source report.

Tips & Tricks #8: MicroStrategy VLDB Properties Hierarchy

Very Large DataBase

VLDB is an acronym for Very Large DataBase. VLDB properties enable MicroStrategy products to take advantage of the unique optimizations that different databases offer. There are over 100 settings that affect how the MicroStrategy Engine handles functions such as:

  • Join options (star join, full outer join, and so forth)
  • Metric calculation options (null and zero check during division operations)
  • Query optimizations (subqueries and driving tables)
  • Table types (temporary or derived tables)

These settings, along with other settings, directly modify how the SQL Engine writes SQL against the warehouse.VLDB Hierarchy

VLDB Properties

The diagram above illustrates how VLDB properties that are set for one level will take precedence over those set for another level.

DBMS Level

The default value for every VLDB property is based on the database type of the warehouse and is written into the metadata at the time that you configure the project. MicroStrategy supplies the default values for the DBMS level, which are optimized for the database type and version.

The VLDB properties values are inherited from the DBMS object when you have not changed any VLDB properties (and all the Use default inherited value check boxes are selected for every VLDB property in the VLDB Properties Editor).

Database Instance Level/Project Level

In the MicroStrategy platform, the Database Instance level and Project level settings are merged together (or considered to be one overall level), because only one database instance can be applied for each project. Also, the Project level settings contain the Analytical Engine-related VLDB properties and the MDX VLDB properties.

Yield Red SignWhen you change a VLDB property setting at the database instance or project level, you must restart the Intelligence Server for the MicroStrategy Engine to read the latest schema information from the metadata.

Report Level

Properties you set at the report level override properties at every other level. For example, if a VLDB property is set to one particular value for a report and the same VLDB property is set to a different value for a metric on that report, the report-level setting takes precedence over the metric-level setting for that VLDB property.

Template Level

Values set at the template level override those at the metric, database instance, and DBMS levels.

Attribute/Transformation Level

There are only a select number of VLDB properties available within the Attribute Editor and the Transformation Editor. If you alter these properties, they automatically override the values for the same properties at the database instance and DBMS levels.

Use default inherited value Check Box 

By default, all objects in a project, including the project itself, have the Use default inherited value check box enabled for all of the VLDB properties (see screenshot below). As mentioned earlier, when you have not changed any VLDB properties and all the Use default inherited value check boxes are selected for every VLDB property in the VLDB Properties Editor, the values are inherited from the DBMS level. If you customize the settings for a VLDB property at  particular object’s level (whether it is a metric, template, project, etc.), any objects above it (in the VLDB Hierarchy) automatically accept the custom setting as the inherited value.

Tip 8-2

Example: Sub Query Type VLDB Property

As an example, let’s review the Sub Query Type VLDB property.

Suppose you define the Sub Query Type VLDB property at the template level to use temporary tables instead of sub queries. You create a new report using the template. When you view the Sub Query Type VLDB property at the report level, you notice that the same value (use Temporary Table) is automatically inherited at the report level. The report inherits the template’s VLDB value because the Use default inherited value check box is enabled (and the check box even lists “Template level” as the level from which the report inherited the custom value). This behavior of inheriting the custom value (as long as long as the Use default inherited value check box is enabled) occurs in a recursive fashion all the way to the DBMS object.


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 michael@dataarchaeology.net. I will do my best to answer your questions.

Best Regards,


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.



Tips & Tricks #6: How the Incremental Refresh Option Works in MicroStrategy 9.4.x

Starting with MicroStrategy 9.2.1, Intelligent Cubes have a new feature to update information without republishing it. It is referred to as Incremental Refresh. There are different ways each Incremental Refresh type option works.

Defining an Incremental Refresh Report

Prior to MicroStrategy 9.2.1, if the data in an Intelligent Cube needed to be updated, users had to re-publish the Intelligent Cube,  either manually or using a schedule. This process will cause all the data for the Intelligent Cube to be loaded from the data warehouse into Intelligence Server’s memory, so that the existing data for the Intelligent Cube is overwritten.

MicroStrategy 9.2.1 introduced a new feature known as Incremental Refresh Options, which allow Intelligent Cubes to be updated based on one or more attributes by setting up incremental refresh settings to update the Intelligent Cube with only new data. This can reduce the time and system resources necessary to update the Intelligent Cube periodically.

For example, if a user has an Intelligent Cube that contains weekly sales data, the user may want this Intelligent Cube to be updated at the end of every week with the sales data for that week. By setting up incremental refresh settings, he can make it so that only data for one week is added to the Intelligent Cube, without affecting the existing data and without having to reload all existing data.

Users can select two types of objects for the incremental fetch: a report or a filter.

  • Filter: The data returned by a filter is compared to the data that is already in the cube. By default, the filter defined for the Intelligent Cube is used as the filter for the incremental refresh.
  • Report: The results of a report are used to populate the Intelligent Cube. By default, the report template used is the same as the Intelligent Cube’s template.

In order to set up an incremental refresh report, the user should first right-click on the Intelligent Cube and select Define Incremental Refresh Report:

This will bring up the Incremental Refresh Options editor:

Here, the user can define one of the following Refresh type options:

  • Update:  If new data is available, it is fetched and added to the Intelligent Cube, and if the data returned is already in the Intelligent Cube, it is updated where applicable.
  • Insert:  If new data is available, it is fetched and added to the Intelligent Cube. Data that was already in the Intelligent Cube is not altered.
  • Delete: The data that meets the filter or report’s definition is deleted from the cube. For example, if the Intelligent Cube contains data for 2008, 2009 and 2010, and the filter or report returns data for 2009, all the data for 2009 is deleted from the cube.
  • Update only: If the data available is already in the Intelligent Cube, it is updated where applicable. No new data is added to the Intelligent Cube.

The type of object used for the incremental fetch can be selected in the Advanced tab:

Users simply have to run the incremental fetch report, and this will automatically refresh the data in the Intelligent Cube.

Incremental Refresh Options Examples

In this example, the following database table is used. This is a transaction table for item, status, quantity sold (qty_sold) and transaction number.

Cube definition:

Report Objects:

– Item

– Status

– Transaction Number

– Quantity

Filter: Transaction Number greater than or equal to 100

Initial data:

Data is updated as below on the database side:

Line 2 – qty_sold number is updated

Line 3 – status is altered from confirmed to canceled

Line 4 – newly added

Line 5 – newly added


Insert new rows from report data and overwrite overlapping rows between old cube data and report data.

Line 2 – qty_sold number is updated.

Line 3 – Status canceled row is newly inserted, and line 4, the original data is not modified. For any change for any other attribute, a new line is added and the previous line also persists.

Line 5 – Newly added transaction is inserted.

And the new data with transaction_number 1 is not added because it does not meet the filter criteria to have transaction_number >= 100.


Only insert new, non-overlapping rows from report data.

Line 2 – qty_sold number is NOT updated.

Line 3 – Status canceled row is newly inserted.

Line 5 – Newly added transaction is inserted.

And the new data with transaction_number 1 is not added.


Remove overlapping rows from old cube data.

Delete Incremental Refresh report is not executed against the warehouse, and executed for Intelligent Cube with the following query. All the data meeting the criteria is deleted.


Delete from CUBE  IncrementalRefreshTestwhere [Transaction Number]@[transaction_date] >=  100


Only overwrite overlapping rows from report data.

Line 2 – qty_sold number is updated.


In summary, when defining an Incremental Refresh report, take the following behavior into consideration.

  • Update/Update only option does not compare all the attribute elements.
  • Delete option is performed on the Intelligent Cube, and data is not compared with the warehouse.

Tips & Tricks #5: Designing MicroStrategy Documents for Exporting to Excel


The following best practices will help ensure that your document is displayed correctly when it is exported to Microsoft Excel. When you export to Excel, the resulting spreadsheet looks like a PDF of the document. For example, objects have the same position and size in Excel that they do in a PDF.

For steps to export a document to Excel, see the section Exporting a document in MicroStrategy Web later in this blog entry.

When designing a document that might be exported to Excel, do the following to ensure that the document is displayed correctly in Microsoft Excel:

  • Know how different object types are exported and displayed in Excel, as shown in the following table:


  • Choose Excel-compatible colors for all objects, including panels, shapes, and Grid/Graphs. Use the set of 40 colors that appear in the Color dialog box in the Document Editor. Excel supports these 40 colors in addition to many more. Other colors are matched by Microsoft Excel as closely as possible. Avoid using gradient colors, since they are not exported to Excel.

Tip 5-2

1 Excel Fill Colors


2 Excel Font Colors

  • Use graph styles that are supported by Microsoft Excel. For example, if you include a Gauge graph in the document, it is not displayed in Excel. If you include a Combination graph, the exported version in Excel may not be displayed exactly like the original graph in MicroStrategy Web.
  • Avoid overlapping objects. When exported, the document may not be displayed correctly. For example, an object in the background of the document may be displayed in the foreground of the Excel spreadsheet.
  • Provide extra space around objects because they may increase in size when the document is exported to Excel.
  • Use text field borders to create lines and rectangles. Standard MicroStrategy line and rectangle controls may not be displayed correctly in Excel. You can also use a panel stack to create a colored background; for instructions to create panel stacks, see the Dashboard Creation Guide.


3 Excel Border (Line) Colors and Weights

Avoid inserting line breaks within text fields. Line breaks (inserted by typing CTRL+ENTER) are not rendered in Excel.

  • Do not enable word-wrapping in a column header on a Grid/Graph in MicroStrategy. If you do so, the headers are not displayed correctly in Excel or PDF. Enable word-wrapping in Excel after you export the document.


4 Turning off Word Wrap in MicroStrategy


5 Turning off Word Wrap in Excel

  • Use an absolute file path to define the location of an image used in a document. Do not use a relative file path. Images in documents specified with paths relative to MicroStrategy Web and Intelligence Server are not displayed when exported to Excel.

Exporting a document in MicroStrategy Web

Exporting a document allows you view and interact with the document results outside of MicroStrategy Web. For example, you can view results in a PDF file within Adobe Reader, manipulate exported data in an Excel spreadsheet, or create an interactive Flash dashboard for off-line use.

You can export a document to the following formats:

  • PDF file: Export the document to a PDF file in a reader, such as Adobe Reader. You can view the PDF on any device with a PDF reader, such as another computer, a Linux machine, a Nook, or a Kindle.
  • Excel spreadsheet (.xls): Export the document to a Microsoft Excel spreadsheet for further manipulation and use. See the Document Creation Guide for tips to create a document that will display correctly when it is exported to Excel.
  • HTML file: Export the document to an html file in a separate window.
  • Flash file: Export the document to a fully interactive, stand-alone Flash file. All the Flash files in a project are exported in one of the following formats:
  • MHT format, which can be opened in Internet Explorer, and in Firefox with a third-party plug-in

The document designer determines the Flash file format.

You are prompted for the following when you export a document, unless the document designer has specified the default exporting options for the document:

  • If your document is grouped, you can choose to export the entire document or only the selected group element. Page-by allows you to view the document by a selected group element.
  • If your document contains multiple layouts, you can choose to export the entire document or only the layout currently being viewed by the user.
  • You can export a document from within the document, or directly from a folder. The following procedures describe both tasks. You can also export a single Grid/Graph to a PDF file or an Excel spreadsheet.

To export an open document

  1. In MicroStrategy Web, click the name of the document to execute it.
  2. From the Home menu, select Export, then select the file format in which to export the document. The options are:
    • Excel
    • HTML
    • PDF
    • Flash

       If an export format is not available on the toolbar, that export format has not been made available for this document.

3. Depending on the file type, you may be prompted to open or save the exported file. You can choose to either:

  • Open the file, by clicking Open. A copy of the document opens in a browser.
  • Save the file, by clicking Save. Name and save the file. Do not change the file type.

To export a document directly from a folder

  1. In MicroStrategy Web, right-click the document and select Run as.
  2. If the document contains prompts, answer them and click Export.
  3. If DHTML is disabled, click the Export icon or PDF icon in the Actions column.

*        If an export format is not available on the toolbar, that export format has not been made available for this document.

4. If DHTML is enabled, select the format to export to:

    • To export to a PDF, select Export to PDF.
    • To export to Microsoft Excel, select Export to Excel.
    • To export to HTML, select Export to HTML.
    • To export to Flash, select Export to Flash.

5. Depending on the file type, you may be prompted to open or save the exported file. You can choose to either:

    • Open the file, by clicking Open. A copy of the document opens in a browser.
    • Save the file, by clicking Save. Name and save the file. Do not change the file type.

Exporting a Grid/Graph from a document

You can export a single Grid/Graph displayed in a document to either a PDF file or an Excel spreadsheet. This provides additional flexibility to share and print your data, so that you do not have to export the entire document.

The document must be displayed in Express or Flash Mode. In Express Mode, the title bar of the Grid/Graph must be displayed. The following procedures describe both tasks.

*         A widget is exported as a Grid/Graph.

To export a Grid/Graph from Express Mode

  1. In MicroStrategy Web, open the document in Express Mode.
  2. Click the icon on the title bar of the Grid/Graph and point to either Export to PDF or Export to Excel.
  3. If you choose PDF, the PDF file opens in another browser window.
  4. If you choose Excel, you are prompted to open or save the exported file. You can choose to either:
  5. Open the file, by clicking Open. A copy of the document opens in another browser window.
  6. Save the file, by clicking Save. Name and save the file. Do not change the file type.
  7. In MicroStrategy Web, open the document in Flash Mode.
  8. Hover your cursor over the Grid/Graph. Icons for exporting to Excel and to PDF are displayed.
  9. Do one of the following:

To export a Grid/Graph from Flash Mode

  • To export the Grid/Graph to Excel, click the Export to Excel icon. You are prompted to open or save the exported file. You can choose to either:
  • Open the file, by clicking Open. A copy of the document opens in another browser window.
  • Save the file, by clicking Save. Name and save the file. Do not change the file type.
  • To export the Grid/Graph to PDF, click the Export to PDF icon. The PDF file opens in another browser window.