Fixing undefined values in a DirectQuery model by normalizing casing in the source query

PL-300 By islever Editorial Last updated

Profile and clean the data

Short answer

A Yes, normalizing casing in the source query or Power Query Editor is the documented fix for undefined values from case-sensitive DirectQuery sources.

Question

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 data source that contains a column. The column contains case sensitive data. You have a Power BI semantic model in DirectQuery mode. You connect to the model and discover that it contains undefined values and errors. You need to resolve the issue. Solution: You normalize casing in the source query or Power Query Editor. Does this meet the goal?
  1. Yes Correct Answer
  2. No

Key Takeaways

The Power BI engine is case-insensitive, so a case-sensitive source feeding DirectQuery can collide duplicate-looking rows into undefined values — normalizing the casing in the source query or Power Query is one of the two remedies the official data types note prescribes.

A case-sensitive column produces undefined values and errors when consumed by a case-insensitive DirectQuery semantic model, and the proposed fix is to normalize casing in the source query or Power Query Editor.

Common mistake: Believing casing normalization is unrelated to 'undefined values' — the official note ties undefined values and errors in DirectQuery directly to case-sensitive data from the source, and casing normalization is a documented cure.

Expert Analysis

Why the Answer Is Correct

The goal states the DirectQuery model contains undefined values and errors caused by case-sensitive source data. Microsoft's data types documentation explicitly notes that because the Power BI engine stores and queries data case-insensitively, case-sensitive values from a DirectQuery source can surface as undefined values, and it lists normalizing the casing in the source query or in Power Query Editor as a way to resolve the issue. The proposed solution is therefore a documented remedy that meets the goal.

Why the Other Options Are Wrong

The only alternative answer would claim the solution does not meet the goal, but that contradicts the official note: no other change is required for the casing problem itself, and the solution name-drops exactly the two locations (source query or Power Query Editor) the documentation recommends. Option B would only be defensible if the solution had proposed an unrelated fix such as changing column data types or removing column profiling.

Community Comment Notes

A commenter with several endorsements links the official desktop data types page and directs readers to the note near the bottom of it, which supports Yes. Dissenting comments argue that undefined values require checking column quality and profiling instead, but those steps diagnose the problem rather than fix it, and the question asks whether the stated solution resolves it.

Official Reference

https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-data-types

This link opens the official vendor documentation in a new tab.

Exam Strategy

When a DirectQuery model shows undefined values because the source column is case sensitive, look for whether the proposed fix normalizes casing in the source query or Power Query Editor; that exact phrase is the documented remedy. Do not pick an answer based on column quality or profiling steps, since those diagnose the issue rather than resolve the casing mismatch. If the solution instead changes data types or removes profiling, treat it as wrong for this goal.

Frequently Asked Questions

Why do case-sensitive source values cause undefined values in a DirectQuery Power BI model?

Power BI stores and queries data case-insensitively, so DirectQuery case-sensitive values can surface as undefined until casing is normalized in the source query or Power Query Editor.

Does normalizing casing in the source query or Power Query Editor meet the goal?

Yes, the proposed solution (A) is Microsoft's documented remedy for undefined values caused by case-sensitive DirectQuery data, so no other change is required for the casing issue.

Why is option B incorrect for this PL-300 DirectQuery question?

Option B would only be defensible if the solution changed column data types or removed column profiling; those actions diagnose or miss the casing issue rather than resolve the undefined values.

More PL-300 FAQ →

Community Votes

A
79%
B
21%

79% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 11 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 11

  1. f3ecb98 👍 4 Answered A
    This exact scenario is explained in the docs (at the "Case sensitivity" part): https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-data-types. According to Microsoft, normalize casing in the source query should be the solution.
  2. Srilatha_B 👍 4 Answered A
    https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-data-types See Note as you scroll down
  3. jaume 👍 3
    In Q36 I voted "No" answer as converting values to required types maybe could fix some unidentified values but I don't think that would fix the errors. Now, although information in the link shared by f3ecb98 and fgo states details bout case sensitivity difference in the PBI engine and PBI tool, I should keep opinion normalize casing could fix some undefined values but don't think this could fix the errors so my vote is for the second option B.No
  4. dpkamalarani 👍 3
    Answer is no, direct query mode cannot be edited in power query
  5. VladStan 👍 2
    The questions says "OR": So, either "Power Query Editor" (which is IMO wrong due to Direct Query mode) OR "You normalize casing in the source query" (which is true, again IMO) I would say that the answer is "A - Yes"
Show 6 more comments
  1. Garrison 👍 2 Answered A
    Why is every question so convoluted lol, theres like 3 total questions in this thing that everyone agrees on
  2. aa83599 👍 2 Answered B
    'Undefined Values' cannot be fixed by adjusting casing
  3. fgo 👍 1
    For me Answer is NO I didn't see how "normalize casing in the source query or Power Query Editor" can address the issue of undefined values and errors in the model ?
  4. SylUK 👍 1 Answered A
    A is the answer because the main objective of normalization, is to eliminate redundancy, minimize data modification errors and simplify the query process.
  5. BhavnishM 👍 1 Answered B
    You need to check the column quality, column profile to solve the issue. Changing the CASE will not resolve undefined errors.
  6. hy00 👍 1
    I think the given answer is correct

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

PREVIOUSYEAR returns the full previous year, not the same day of last year

S-grade

Shrinking a Power BI model for monthly transaction totals with a star schema

S-grade

Northwind Traders semantic model: choosing Import storage mode for the Power BI tables

S-grade

Connecting Power BI Desktop to Azure DevOps Analytics views with the OData Feed connector

S-grade

Practice All PL-300 Questions

Access 116 questions with complete answers and detailed explanations.

View Full PL-300 Practice Test →

← Back to PL-300 Study Guide