It is better practice to attach a custom template so you can be sure the style definitions are retained and can be archived with the document(s) associated with them. This will work, but it can create future problems if a different document based on Normal used different settings - and then you re-opened this one. Your instructions cause the TOC styles to be modified for the default template (Normal.dotx). Worse, subsequent levels based on TOC 3 will change as well.Ģ. For some obscure reason, the default is “on” - but with it turned on, any direct formatting change made by a user to an instance of that style will automatically change the style definition! So, if a user decided to make a given TOC 3 line italic, all TOC 3 lines will suddenly become italic. In the Modify Style dialog, be sure to turn off the “Automatically update” checkbox. However, there are two additional points I’d make:ġ.
So you could use CALCULATE (VALUES(.)) to refer to any column accessible by following many=>1 relationships, just like RELATED.Your method is identical to modifying the TOC x styles with the Modify Style dialog - although I grant that accessing it through the ToC dialog may seem more intuitive. Is the same as RELATED ( Column on 1-side of relationship ) VAR T = //which is the expanded Fact table corresponding to current rowįor all intents and purposes in a calculated column, CALCULATE ( VALUES ( Column on 1-side of relationship ) ) Is translated to something like: Dim Name = So the calculated column added to 'Fact' Dim Name = CALCULATE(VALUES(Dim)) The expanded table lets you access columns on the 1-side of the relationship. Whenever a physical table is added to the filter context via CALCULATE, it is interpreted as the expanded verison of the table.įrom the article above, this can be interpreted as the expanded table being added to the filter context first within an outer CALCULATE, then an inner CALCULATE is performed with the actual filter arguments specified (none in your example). (see the section Understanding the Evaluation Order)Īs I understand it, when CALCULATE() is called within the row context of a physical table (such as in a calculated column), the physical table (corresponding to the current row) is added to the filter context. I won't pretend this is a complete explanation.įirst off, this is probably a good reference article I recall reading: How does the DAX engine decide which table / expanded table to use in the evaluation? Maybe the Dim values are coming from the expanded Fact table. I though maybe VALUES is doing something special, but can't see how MIN or similar functions do anything fancy.
I don't get how the row to filter transformation has any impact on the Dim table. But I'm struggling to understand why it works.Īnd Dim Name 2 = CALCULATE(MIN(Dim)) I tried two methods of caculated columns in the Fact table both producing the correct (data wise) result.
Now for the part I though I understood until the concept of Expanded Tables was introduced to me. The column expression is per below and produces the expected result for each row, as CALCULATE transforms the row context to filter context and when counting the rows of Fact the expanded table has the related columns with filters on them.įact Count = CALCULATE(COUNTROWS('Fact')) I try a similar concept in a calculated column of Dim table. I create a measure as follows as it produces the correct result on a matrix with rows as Dim or Dim because the expanded Fact table contains those columns which will have the query / initial filter value per the row in the matrix. I feel I have a good understanding of explaned tables now, but this bit I cannot work out.simple example I've created:ĭim table has no expanded / related columns, just the native ones.
0 kommentar(er)
