IGLOO BI

What distinguishes a "pro" from an "intermediate" user in Power BI? It is whether they understand and use functions based on their intrinsic roles. While many users try to handle both filter removal and table creation using only the ALL function, in the world of large-scale models, this slight ambiguity leads to maintenance nightmares and performance bottlenecks. In 2019, Microsoft introduced the dedicated tool REMOVEFILTERS for very clear reasons: Intent: Is the calculation logic immediately clear upon reading the code? Structure: Is it preventing the unnecessary creation of virtual tables? Performance: Can the engine modify the filter context in the most efficient way? Beyond a simple syntax comparison, discover how to use REMOVEFILTERS to complete the aesthetics of your DAX design.   1. Historical Background: An Evolution That ALL Could Not Handle Alone 1) ALL – The "Solitary Founding Member" of the Power Pivot Era The ALL function was introduce...

DAX Optimization Technique: Execution-Aware DAX Design When a Power BI report is slow, most users suspect the following: Is it because the data volume is too large? Is the visualization too complex? Are functions like SUMX or CALCULATE too heavy? However, the real cause most frequently encountered in practice is something else entirely: the developer is unaware that the engine is performing unnecessary calculations "until the very end." This post addresses exactly that point. Today, we will explore "Execution-Aware DAX Design"—the core of DAX performance optimization—and the "Early Exit" technique, which physically removes unnecessary operations.   1. Why Does DAX Calculate Useless Things Until the End? DAX is inherently a language that "seeks to preserve meaning." While general programming decides its path based solely on the "current value," DAX is a perfectionist that considers data relationships and every possible change. Let’s u...

The first step to mastering DAX is understanding the "identity of a value." You must clearly define whether what you are creating is "fixed historical data" or a "real-time response" that changes based on a user's question. 1. Calculated Column: A Fixed State Determined at Data Loading A Calculated Column is computed row by row during the data refresh process and is physically stored as a value within the data model. Once calculated, it does not change based on slicers or filters in the report. Calculation Timing: Performed only once during the data refresh. Operating Principle (Row Context): It scans each row one by one and completes the calculation using only the values present in that specific row. System Characteristics: Slicers or filters on a report cannot change the "result value" of a Calculated Column. Slicers merely determine "which rows to show" (Visibility). Primary Uses: Values to be used as slicer items (e.g., Age Gr...

Power BI’s Hidden Trap: Rows are OK, but Total is BLANK? Anyone who has spent a fair amount of time analyzing data with Power BI will eventually encounter this baffling scene: "The amounts for individual rows are displayed perfectly, but the crucial Total has vanished into a blank space." When first facing this phenomenon, most people fall into the same misconceptions: "Is it a visualization option issue? Did the 'Show Total' setting get turned off?" "Is this a bug within Power BI itself?" "Is there a problem with the data connection?" However, let me start with the conclusion: this is not a bug. It is the result of DAX (Data Analysis Expressions) performing exactly as intended. It is a natural (?) phenomenon that occurs when we haven't quite grasped the core DAX concept of 'Filter Context.' In this post, I will dive deep into why this happens when using conditional calculations like IF and RANKX, why this problem is particul...