Spot duplicates and conflicts in a table
Choose a record key and separate exact repeats from competing values before removing rows.
Follow the method ↓
The answer in 30 seconds
Two rows may be identical because of a double import, or they may represent two real events. A shared name is not a unique identity. The first decision is what one row is supposed to represent.
Define the observation and its key, work on a copy, group candidate repeats, compare every meaningful field, then resolve conflicts using the source rather than keeping an arbitrary row.
Examples to adapt
Matching names may still refer to different people; look for a stable authorised identifier.
The same location can correctly appear once per month.
If one key has two amounts, return to the source or record the conflict instead of choosing the larger value.
Follow the method
- 1Define one row
Write the event, person or period that each record represents.
- 2Choose a key
Select fields that should be unique together, such as record ID plus reporting period.
- 3Group candidates
Use a filter or comparison on a copy and distinguish exact matches from field conflicts.
- 4Resolve and recount
Document each removal or merge, then compare counts and totals with the original.
A closer look
Choose the key before deleting a row
Fictional example: a table counts visits by facility and month. The expected key combines those two fields rather than just the facility name.
| Compared rows | Diagnosis | Action |
|---|---|---|
| A; January; 12 / A; January; 12 | Exact copy across observed fields | Check provenance before retaining one copy |
| A; January; 12 / A; February; 12 | Two different months | Keep both observations |
| A; January; 12 / A; January; 15 | Same key with conflicting measurements | Seek a corrected version or ask the producer |
A key identifies a potential problem; it does not select the correct value. Record row counts before and after each decision.
Is the last row necessarily correct?
No. Row order is not a priority rule. You need a version date, correction status or explicit producer instruction.
A checklist to keep
Use these checks to record what you found. The grid supports a decision; it does not make one for you.
| Check | What to examine | Action |
|---|---|---|
| Observation | What does one row describe? | Define |
| Key | Which fields identify it? | Choose |
| Match | Are all fields identical? | Compare |
| Conflict | Which values disagree? | Investigate |
| Impact | How do counts change? | Measure |
Read the checklist directly in the table.
What to check
Filtering unique values may be case sensitive depending on the tool.
Matching one column is rarely enough to prove a duplicate.
Removing a row can change totals and rates.
Common questions
Can I press 'Remove duplicates' immediately?
Only after confirming the selected columns represent a unique observation and preserving a copy.
What if records disagree?
Keep a conflict list and check the source; a formula cannot decide which observation is true.
Sources and documentation
Documentation consulted on . Examples are illustrative; interfaces and results may change.