Optimizing DAX Queries with ISEMPTY in Fabric
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have a Fabric tenant that contains a semantic model named Model1. You discover that the following query performs slowly against Model1. You need to reduce the execution time of the query. Solution: You replace line 4 by using the following code: ISEMPTY ( RELATEDTABLE ( 'Order Item' ) ) Does this meet the goal? - 
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The core concept is using ISEMPTY for efficient row existence checks; the trap is confusing the boolean return value of ISEMPTY with the desired filter logic (empty vs. not empty).
This question tests the correct use of the ISEMPTY function in DAX to optimize query performance on semantic models. The proposed solution fails because it reverses the logical condition required for the filter context.
Learners often select 'Yes' because they recognize ISEMPTY as a valid, fast function, but fail to realize that wrapping it directly in a filter argument without NOT inverts the result, showing empty tables instead of populated ones.
Community Discussion (8 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The correct answer is B (No) because the proposed codeISEMPTY( RELATEDTABLE('Order Item') ) returns TRUE when the related table is empty and FALSE when it has rows. In a typical filtering scenario aimed at finding records with associated items, you need to keep rows where the table is NOT empty. Therefore, the logic is inverted.Why the Other Options Are Wrong
Option A is incorrect because the solution does not meet the goal of reducing execution time while maintaining correctness; it produces wrong results. Even if performance were improved by using ISEMPTY over COUNTROWS, the data output would be incorrect due to the missing NOT operator.Community Comment Notes
The community consensus strongly supports Option B. Users like Chrys941 and Lucetmi noted that "NOT ISEMPTY" is the required syntax. Bigdave987 pointed out that the current logic shows where COUNTROWS equals zero, which is the opposite of the likely intent. Stilferx also confirmed that "NOT EMPTY" is needed to preserve the original meaning.Exam Strategy
When optimizing DAX queries, always verify the logical outcome of your functions. If replacing a slow function like COUNTROWS with a faster one like ISEMPTY, ensure you apply the necessary boolean operators (NOT) to maintain the correct filter semantics.
Frequently Asked Questions
Why is ISEMPTY faster than COUNTROWS?
ISEMPTY checks for the existence of any row without counting them, which avoids aggregation overhead.
How do I fix the ISEMPTY logic error?
Wrap the function in NOT, e.g., NOT ISEMPTY(...), to keep rows where the table is not empty.
Related Analysis
Practice All DP-600 Questions
Access 115 questions with complete answers and detailed explanations.
View Full DP-600 Practice Test →