Stata Errors
2026-02-106 min read

Stata 'not sorted' Error in Merge: The Fix That Takes 5 Seconds

Stata says your data is not sorted. The fix is one line — but understanding why prevents hours of debugging merge issues.

Sytra Team
Research Engineering Team, Sytra AI

You try to merge two datasets and Stata says your data is not sorted. The fix is one line. But understanding why prevents hours of merge debugging.

. merge id using schools.dta
variable id does not uniquely identify observations in the master data
not sorted
r(5);

All examples tested in Stata 18 SE. Compatible with Stata 15+.


Quick Answer

quick-fix.do
stata
1// Fix 1: Sort before merging (old syntax)
2sort id
3merge id using schools.dta
4
5// Fix 2: Use modern merge syntax (no sorting needed)
6merge 1:1 id using schools.dta
7
8// Fix 3: Sort both datasets
9sort id
10save master_data.dta, replace
11use schools.dta, clear
12sort id
13save schools.dta, replace
14use master_data.dta, clear
15merge 1:1 id using schools.dta

Best fix: Use the modern merge syntax (merge 1:1, merge m:1,merge 1:m). It doesn’t require pre-sorting and gives better error messages.


Old Merge vs. Modern Merge

Stata has two merge syntaxes. The old one requires sorting. The modern one (Stata 11+) doesn’t.

Old syntax — requires sorting
stata
// Must sort both datasets first!
sort student_id
merge student_id using test_scores.dta
// You also need to sort the using dataset
// before saving it
Modern syntax — no sorting needed
stata
// No sorting required
merge 1:1 student_id using test_scores.dta
// Or for many-to-one:
merge m:1 school_id using school_data.dta
// Or for one-to-many:
merge 1:m firm_id using employee_data.dta
💡Always use modern merge
There is no reason to use the old merge syntax in 2026. The modern syntax (merge 1:1,merge m:1, merge 1:m) is clearer, doesn’t require sorting, and creates the _merge variable automatically. If you see code without the type specifier, it’s legacy code.

When Sorting Isn’t Enough: Duplicates

Sometimes you sort your data and still get merge errors. This usually means you have duplicate keys where uniqueness is expected.

check-duplicates.do
stata
1// Check if your merge key is unique
2isid student_id
3// If this fails, you have duplicates
4
5// Find the duplicates
6duplicates report student_id
7duplicates tag student_id, gen(dup)
8list student_id name if dup > 0
9
10// Decide what to do with duplicates:
11// Option A: Keep first occurrence
12duplicates drop student_id, force
13
14// Option B: Investigate and fix the data
15browse if dup > 0
. duplicates report student_id
Duplicates in terms of student_id

--------------------------------------
   Copies | Observations       Surplus
----------+---------------------------
        1 |        9,847             0
        2 |          306           153
--------------------------------------

In this example, 153 student IDs appear twice. You need to resolve these before a merge 1:1will work. Either deduplicate, or use merge m:1 if the duplication is intentional (e.g., panel data with multiple years per student).

⚠️duplicates drop is destructive
duplicates drop, force keeps only the first occurrence. If different duplicates have different values for other variables, you’re silently losing data. Always investigate duplicates before dropping them.

Choosing the Right Merge Type

TypeMasterUsingExample
1:1Unique keyUnique keyStudent ↔ test score
m:1Repeated keyUnique keyWorkers ↔ firm characteristics
1:mUnique keyRepeated keyFirm ↔ worker records
merge-types.do
stata
1// One student, one test score
2merge 1:1 student_id using test_scores.dta
3
4// Many workers per firm, one firm characteristic row
5merge m:1 firm_id using firm_data.dta
6
7// One firm, many worker records
8merge 1:m firm_id using worker_data.dta
9
10// Always check the merge results
11tab _merge
. tab _merge
     Result from  │
          merge   │      Freq.     Percent        Cum.
──────────────────┼───────────────────────────────────────
  Master only (1) │        247        2.47        2.47
   Using only (2) │        183        1.83        4.30
      Matched (3) │      9,570       95.70      100.00
──────────────────┼───────────────────────────────────────
            Total │     10,000      100.00

Pre-Merge Safety Checks

pre-merge-checks.do
stata
1// Before ANY merge, run these checks:
2
3// 1. Verify key uniqueness (for 1:1 or the "1" side of m:1)
4isid student_id
5
6// 2. Check for missing values in the key
7count if missing(student_id)
8
9// 3. Check the key type matches
10describe student_id
11// (prevent type mismatch errors)
12
13// 4. Check overlap
14// How many keys from master appear in using?
15preserve
16use schools.dta, clear
17levelsof school_id, local(using_ids)
18restore
19// Compare with master dataset school IDs

Sytra catches these errors before you run.

Sytra automatically validates merge keys — checking uniqueness, type compatibility, and expected match rates — before running the merge. No more debugging sort errors or silent mismatches.

Join the Waitlist →

FAQ

Why does Stata say “not sorted” when I try to merge?

The old merge syntax (without 1:1, m:1, or 1:m) requires both datasets to be sorted on the merge key. The modern merge syntax does NOT require sorting. Switch to merge 1:1 id using data.dta.

How do I fix the “not sorted” error?

Either sort both datasets with sort id before merging, or use the modern merge syntax which doesn’t require pre-sorting. The modern syntax is always preferred.

Do I need to sort before merge 1:1?

No. merge 1:1, merge m:1, and merge 1:m do not require pre-sorting. Only the legacy syntax (no type specifier) requires it.

Why does sort not fix my merge error?

You likely have duplicate keys. Run isid varname to check uniqueness andduplicates report varname to find duplicates.


Written by Sytra Team
Research Engineering Team, Sytra AI

We build practical, reproducible workflows for Stata and R teams working on real empirical research pipelines.

#Stata#Errors#Merge#Data Management

Enjoyed this article?