IGLOO BI

Many people memorize the sentence, "CALCULATE transforms a row into a filter," yet they find themselves helpless when faced with errors in practice. The cause of this problem is not simple. The core issue is not merely that "transition occurs," but rather when and within what scope that transition is actually applied. To understand this mechanism most intuitively, we will introduce two concepts: The Eyes (Row Context): The gaze that reads through data line by line (Iterative functions). The Hands (Filter Context): The power to reconstruct the environment based on the information read (CALCULATE). Today, through three comparative scenarios—Measures A, B, and C—we will perfectly master how results change dramatically when only the 'Eyes' are open versus when the 'Hands' move together, and how to restore our Totals to nor...

In Power BI, the most powerful and simultaneously the most misunderstood function is undoubtedly CALCULATE . Many users operate under the following assumption: “Since it is inside CALCULATE, the SUM will be calculated first, and then the filter will be applied, right?” To put it bluntly, it is exactly the opposite. CALCULATE in DAX does not execute procedurally. In other words, it is not structured to execute "from top to bottom" like C or Python; rather, it is a method where filters are defined first → the environment is reconstructed → and then the expression is evaluated upon that foundation. Therefore, it is more accurate to understand CALCULATE not merely as a function, but as an "engine that redesigns the calculation environment." In this post, we will precisely organize the internal execution order (timeline) of CALCULATE based on actual example data. ...

When using the FILTER function inside CALCULATE , deciding whether to set the stage with ALL or VALUES is a critical design choice. It determines whether you will "acknowledge the authority of external slicers or completely ignore them." By comparing the two codes side-by-side, let us analyze how the results of independent evaluations within the engine differ. 1. Example Data for Analysis: SalesData (Fact Table) This data contains 20 transactions that occurred during a single day. Date Time ID ProductName Category SalesAmount 2024-01-01 8:30 C01 Americano Beverage 45 2024-01-01 8:45 C02 Cafe Latte Beverage 8 2024-01-0...

When working with Power BI, you will eventually encounter a moment where you ask: "It's clearly the same logic... so why are the results different?" Specifically, the experience of getting completely different results depending on whether you used a VAR or not is an almost essential rite of passage for practitioners. This issue is not a simple difference in syntax; it is deeply connected to the Evaluation Timing of the DAX engine. This article clarifies this difference and explains structurally why results vary inside and outside of CALCULATE. 1. The Essence of the Problem: "Same Code, Different Results" Let’s compare the following two codes. The goal is to calculate the 'Average of the last 4 months from the current point.' 1) Case 1: Direct Evaluation Inside CALCULATE (Normal Operation) This method works exactly as we intended, escaping the influence of the sl...