Forum Discussion
Rows Disappear after double ReplaceValue Steps
I've run into something in Power Query that I can't logically explain, and I'm curious if anyone else has seen this before.
I was trying to troubleshoot why a couple of program numbers (Row unique identifiers) were missing from my final dataset. After a lot of debugging, I found that the rows exist prior to a Remove Duplicates step, but disappear afterward, even though they are not duplicates.
I verified that one of the program numbers (7311a) exists exactly once before the Remove Duplicates step. A row count check shows 1 row before and 0 rows after.
What really throws me off is that seemingly unrelated changes to the query make the row come back.
Examples:
Removing the second Changed Type step makes the row appear.
Merging two Changed Type steps into one makes the row appear.
Deleting a random Replace Value step makes the row appear.
Reducing the dataset earlier in the query makes the row appear.
None of those changes should have any relationship to the missing program numbers.
The weirdest part is that I was never able to consistently reproduce the issue in a separate test dataset with non-proprietary data. I can make the issue disappear, but I can't reliably recreate it from scratch.
I also noticed that sometimes I couldn't find the row in Power Query, but it would show up later in a table visual. Other times it was genuinely missing from the final query result.
At this point I'm less concerned about this specific program numbers and more concerned about the possibility that something similar could be happening elsewhere without anyone noticing. In large datasets with merges, deduplication, and row reductions happening all over the place, it seems like it would be very easy for a few records to disappear without throwing an error.
Has anyone seen behavior like this before?
More importantly, how do you validate that Power Query isn't silently dropping records somewhere in a complex model?
Do you have any techniques for auditing row loss beyond manually comparing row counts between steps?
Power BI Desktop Version: 2.155.756.0 (June 2026)
4 Replies
Hi,
Likely cause: query folding + case-insensitive SQL collation. Remove Duplicates is case-sensitive in the M engine, but if that step folds to the source (SQL Server default collation is usually case-insensitive), 7311A and 7311a get treated as duplicates there and one gets silently dropped. Your "unrelated" changes shift where folding breaks, which flips whether dedup happens locally (case-sensitive, keeps both) or at the source (case-insensitive, collapses to one).
Quick test: Add Table.Buffer() right before Remove Duplicates. If the row reappears, that confirms it.
Fix: Buffer before dedup, or dedupe on a normalized helper key (Text.Upper()), or force a binary collation at the source.
Auditing tip: Add a small side query logging Table.RowCount() at each major checkpoint (post-source, post-merge, post-dedupe, post-filter) so silent drops show up automatically on refresh instead of manual comparison.
Sample data that reproduces the problem, along with the M-Code, would help us help you to debug the problem. To obtain the M-Code, on the Home menu select the Advanced Editor; then copy and paste the code that appears into a response here. For sample data, please copy/paste an actual table, rather than a screenshot.
Hi Brett007
Following up to confirm if the earlier responses addressed your query. If not, please share your questions and we’ll assist further.
Hi Brett007
Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.
