Challenge 3: Merge, Not Append — and a Realistic Silent-Mismatch Cause — Solution Walkthrough

This is a Merge, not an Append.

Why:

Append stacks rows from sources that already share the SAME columns
— it would only make sense here if Products and Sales had identical
column layouts and you just wanted to pile their rows together, which
isn't the goal. The actual goal is to add NEW columns (ProductName,
Category) onto the existing Sales rows, matched by a shared key
(ProductID) — that's a join, which in Power Query is a Merge. After
merging, each Sales row gains ProductName and Category alongside its
existing Date and Amount; the row count stays the same as Sales'
original row count (assuming a Left Outer join keeping every Sales
row), while the column count grows.

A realistic cause of silent blank ProductName/Category values even
though every ProductID genuinely exists in both queries:

The ProductID values in one query are stored as genuine NUMBERS,
while in the other query they were imported or typed as TEXT (e.g.
"1024" as text vs. 1024 as a number) — visually identical, but Power
Query's merge match compares the underlying value AND type, and a
text "1024" does not match a numeric 1024. Every row would appear to
have a "matching" ProductID by eye, yet the merge produces blank
ProductName/Category for every single row, because not one of them
actually matches at the type level.

Notes:
- This is the same category of gotcha as this chapter's own warning
  box about exact-match join keys — here it's a data TYPE mismatch
  rather than a case or whitespace mismatch, but the underlying
  lesson is identical: a merge key that looks the same to a human
  reader is not guaranteed to be considered identical by Power Query.
- The fix is a "Change Data Type" step (from this chapter's own
  cleaning-transformations table) applied to the ProductID column in
  whichever query has it as text, converting it to a genuine number
  before the Merge step runs.