Disabling dynamic sourcing for attributes

Attributes are available for dynamic sourcing by default, but there are some data modeling conventions that should be considered when using dynamic sourcing.

In general, if attributes use outer joins, accurate data can be returned to reports from Intelligent Cubes through dynamic sourcing. However, if attributes use inner joins, which is more common, the resulting data set may be incomplete. In such cases, you should verify that the attribute data can be correctly represented through dynamic sourcing.

Two scenarios can cause attributes that use inner joins to return incorrect or incomplete data when dynamic sourcing is used:

Attribute information in lookup and fact tables includes NULL values.
All attribute elements in fact tables are not also present in lookup tables.

These scenarios are uncommon.

If some attributes fit these scenarios, you can disable dynamic sourcing when these attributes are used in reports and Intelligent Cubes. You can enable and disable dynamic sourcing for attributes by modifying the Attribute Validation VLDB property. This VLDB property has the following options:

Attribute columns in fact tables and lookup tables do not contain NULLs and all attribute elements in fact tables are present in lookup tables: This is the default option for attributes, which enables attributes for dynamic sourcing.
Attribute columns in fact tables and lookup tables may contain NULLs and/or some attribute elements in fact tables are not present in lookup tables: This option disables dynamic sourcing for attributes. This setting should be used if your attribute data is not modeled to support dynamic sourcing. The inclusion of NULLs in your attribute data, or a mismatch between available attribute data in your fact and lookup tables, can cause incorrect data to be returned to reports from Intelligent Cubes through dynamic sourcing.

You can disable dynamic sourcing for attributes individually or you can disable dynamic sourcing for all attributes within a project. While the definition of the VLDB property at the project level defines a default for all attributes in the project, any modifications at the attribute level take precedence over the project level definition. For information on accessing the VLDB Properties Editor for a project to define a default dynamic sourcing option for all attributes, see Accessing the dynamic sourcing VLDB properties for a project.

The steps below show you how to disable or enable dynamic sourcing for an individual attribute. If your database is case-sensitive, you should also review Supporting filtering on attributes for dynamic sourcing to ensure that dynamic sourcing can correctly return data for your attributes.

To enable or disable dynamic sourcing for an attribute

In MicroStrategy Developer, browse to an attribute, right-click on it, and select Edit. The attribute opens in the Attribute Editor.
From the Tools menu, select VLDB Properties. The VLDB Properties Editor opens.
From the Tools menu, select the Show Advanced Settings option if it is not already selected.
In the VLDB Settings list, expand Dynamic Sourcing, and then select Attribute Validation.
Clear the Use default inherited value check box.
Select one of the options depending on whether you want to disable or enable dynamic sourcing for an attribute:

To enable attributes to use dynamic sourcing (the default option), select Attribute columns in fact tables and lookup tables do not contain NULLs and all attribute elements in fact tables are present in lookup tables.
To disable dynamic sourcing for attributes unless outer joins are used for the attribute, select Attribute columns in fact tables and lookup tables may contain NULLs and/or some attribute elements in fact tables are not present in lookup tables. This setting should be used if your attribute data is not modeled to support dynamic sourcing.

Click Save and Close to save your changes to VLDB properties and close the VLDB Properties Editor.
Click Save and Close to save the attribute and close the Attribute Editor.

You can track various information related to dynamic sourcing that can help determine why dynamic sourcing succeeded or failed for reports, as described in Tracking the use of dynamic sourcing.

Supporting filtering on attributes for dynamic sourcing

To ensure that dynamic sourcing can return the correct results for attributes, you must also verify that filtering on attributes achieves the same results when executed against your database, versus an Intelligent Cube.

A filter on attributes can potentially return different results when executing against the database, compared to using dynamic sourcing to execute against an Intelligent Cube. This can occur if your database is case-sensitive and you create filter qualifications that qualify on the text data of attribute forms.

If your database is case-sensitive, this is enforced for the filter qualification. However, filtering for an Intelligent Cube is handled by the Analytical Engine which does not enforce case sensitivity.

Consider a filter qualification that filters on customers that have a last name beginning with the letter h. If your database is case-sensitive and uses uppercase letters for the first letter in a name, a filter qualification using a lowercase h is likely to return no data. However, this same filter qualification on the same data stored in an Intelligent Cube returns all customers that have a last name beginning with the letter h, uppercase or lowercase.

You can define attributes to either allow filter qualifications to be completed without enforcing case sensitivity, or to disable dynamic sourcing if these types of filters are used on attributes. You can configure this dynamic sourcing behavior for attributes by modifying the String Comparison Behavior VLDB property. This VLDB property has the following options:

Use case insensitive string comparison with dynamic sourcing: This is the default option for attributes. When attempting to use dynamic sourcing, filter qualifications can qualify on the text data of attribute forms without enforcing case sensitivity.

This is a good option if your database does not enforce case sensitivity. In this scenario, dynamic sourcing returns the same results that would be returned by the filter qualification if the report was executed against the database.
Do not allow any string comparison with dynamic sourcing: This option disables dynamic sourcing for attributes when a filter qualification is used to qualify on the text data of attribute forms.

This is a good option if your database is case sensitive. In this scenario, dynamic sourcing could return different results than what would be returned by the filter qualification if the report was executed against the database.

You can modify this VLDB property for attributes individually or you can modify it for all attributes within a project. While the definition of the VLDB property at the project level defines a default for all attributes in the project, any modifications at the attribute level take precedence over the project level definition. For information on accessing the VLDB Properties Editor for a project to define a default dynamic sourcing option for all attributes, see Accessing the dynamic sourcing VLDB properties for a project.

The procedure below describes how to modify the String Comparison Behavior VLDB property for an individual attribute.

To modify the String Comparison Behavior VLDB property for an attribute

In MicroStrategy Developer, browse to an attribute, then right-click the attribute and select Edit. The attribute opens in the Attribute Editor.
Choose Tools > VLDB Properties. The VLDB Properties Editor opens.
Choose Tools > Show Advanced Settings option if it is not already selected.
In the VLDB Settings list, expand Dynamic Sourcing, and then select String Comparison Behavior.
Clear the Use default inherited value check box.
Select one of the options depending on whether you want to disable or enable dynamic sourcing for an attribute:

Use case insensitive string comparison with dynamic sourcing: This is the default option for attributes. When dynamic sourcing is used, it allows filter qualifications to qualify on the text data of attribute forms without enforcing case sensitivity.
Do not allow any string comparison with dynamic sourcing: This option disables dynamic sourcing for attributes when a filter qualification is used to qualify on the text data of attribute forms.

Click Save and Close twice

You can track various information related to dynamic sourcing that can help determine why dynamic sourcing succeeded or failed for reports, as described in Tracking the use of dynamic sourcing.