Going from the top-down, we start with the report level. This would be the most specific level. All preferences defined at this level (i.e. in each report), will overwrite those defined at lower levels (according to the graphic), but redundantly, they will affect only the report in question. The same applies to Templates. Except for defining a different VLDB property for a particular report, a template can be created to define certain properties that we want to define as a basis when creating a report, without these properties being applied to all new reports (or existing ones, of course!).
Continuing with the hierarchy, we come to the object-level properties. And I know this is where you will tell me: but Joaquin, in the technical note it clearly says “metric”! why do you say “object“? And this is where I explain that at this level not only indicators have VLDB properties, but there are also other objects such as attributes or transformations. So it is important to understand that sometimes adding an attribute to a report can change its behavior about how other attributes are calculated.
Then, we could say that almost simultaneously come Project and DBI. Digo esto porque solo se puede aplicar una instancia de base de datos principal para cada proyecto… pero dependiendo distintas configuraciones se puede aplicar una u otra DBI.
In addition, the project-level configuration contains VLDB properties related to the MDX reporting and analytical engine. And I add, as a colorful fact, that when modifying a VLDB at this level it is necessary to restart the IS for the changes to take effect.
The most basic DBMS (database) level where properties are defined. It sets the general standards. By default, they are defined by MicroStrategy, optimized for the database and its version.
By default, all properties are governed by the one at the top level. This is reflected in the checkbox “Use default inherited value for all VLDB properties”.