The append Command in Stata: Stacking Datasets

Stata’s append command adds the observations from one or more datasets onto the bottom of the dataset already in memory, matching on variable name: append using file2.dta stacks rows, it does not add columns. If two survey waves, two sites, or two country files share the same variables and you want one longer dataset, append is the tool; if you instead want to add new variables about the same observations from a second file, that is a job for merge, not append.

This page covers the append-versus-merge decision, the basic syntax with a worked example, the force option and the variable-type conflicts it papers over rather than fixes, the generate() option for tagging which file each observation came from, and the variable-mismatch pitfalls — misspelled names, conflicting value labels, silently-missing values — that produce data loss with no error message at all.

append vs. merge: stacking rows, not joining columns

The two commands solve different problems, and Stata will not stop you from picking the wrong one — both run without error even when the result is meaningless. Ask which situation you are in:

• Same variables, different observations — three regional survey files, all with the identical id, age, response columns, one file per region. You want three times the rows and the same set of columns. That is append.
• Different variables, same observations — a roster of participant IDs and demographics, plus a separate file of test scores keyed to the same IDs. You want the same number of rows (one per participant) with more columns. That is merge, matched on the shared ID variable, not append.

A shortcut: if the files describe the same kind of record repeated (rows), reach for append; if they describe different facts about the same units (columns), reach for merge. Mixing them up does not crash — appending two files that should have been merged just produces a dataset with more rows and the two files’ variables interleaved with missing values, which is its own kind of silent data loss covered below.

Basic syntax and a worked example

The core syntax is:

append using filename [filename2 ...] [, generate(newvar) force keep(varlist) nolabel nonotes]

filename can be a single dataset or a list of several, all appended in one command. A minimal example: two regional files with identical variables.

. use region_north.dta, clear
. describe
    Variable      Storage   Display    Value
    name          type      format     label      Variable label
    -----------------------------------------------------------
    id            long      %12.0g
    age           byte      %8.0g
    response      byte      %8.0g

. append using region_south.dta
. describe

Contains data
  obs:           420
  vars:             3
------------------------------------------
  id              long    %12.0g
  age             byte    %8.0g
  response        byte    %8.0g
------------------------------------------

Stata reports the number of observations added and, on success, the dataset in memory now holds both regions’ rows under the same three variables. Nothing about the display distinguishes which observations came from which file — for that you need generate(), covered next.

The force option: a permission slip, not a fix

By default, append refuses to combine a variable that is string-typed in one dataset with the same-named variable typed numeric in the other, and stops with an error rather than guessing what you meant. force overrides that check and lets the append proceed — but it does not reconcile the two types intelligently. The combined variable becomes string, and any values that were numeric are converted to their string representation.

That conversion is the trap: the appended dataset looks fine on browse — the numbers are still visible — but the variable is no longer numeric. summarize, regress, or any arithmetic on it either errors out or silently returns nothing useful, and you often do not notice until an analysis step several commands later behaves strangely. A common real cause is an ID variable entered with leading zeros as text in one source file (so Stata reads it as string) and as a plain number in another — force will “solve” the immediate append error by converting the whole variable to string, quietly changing every observation’s type in the process.

Treat a type-mismatch error as a prompt to fix the source data — destring or tostring the offending variable deliberately, in the direction you actually want — rather than reaching for force as the default fix.

generate(): tagging which dataset each observation came from

Once files are stacked, generate(newvar) adds a variable recording provenance: 0 for observations that were already in memory (the master data), 1 for the first using file, 2 for the second, and so on.

. use region_north.dta, clear
. append using region_south.dta, generate(source)
. tabulate source

     source |      Freq.     Percent        Cum.
------------+-----------------------------------
          0 |        210       50.00       50.00
          1 |        210       50.00      100.00
------------+-----------------------------------
      Total |        420      100.00

generate() is cheap insurance: it costs one extra word in the command and lets you later verify the stacking worked as expected, split results by source cohort, or restrict an analysis to a specific file’s observations without re-loading anything.

The variable-mismatch pitfalls that cause silent data loss

These do not throw errors, which is exactly what makes them dangerous — the append command completes, reports success, and the mistake surfaces only later, if at all.

• Misspelled or inconsistent variable names. If one file has gender and the other has sex for what is conceptually the same field, append does not recognize them as equivalent. It creates two separate variables in the combined dataset, each populated only for the observations from its source file and coded missing (.) for the rest. Nothing errors; you simply end up with a variable that is half-empty, and any analysis using it silently drops roughly half your sample.
• Conflicting value labels on the same variable name. If status is coded 1/2/3 with one label definition in file A (1 = Enrolled) and a different label definition in file B (1 = Withdrawn), the appended dataset keeps one label mapping and applies it across all observations — so numbers from the other file display under the wrong label even though the underlying stored value is untouched. Run label list on both files before appending, not after.
• Numeric storage-type mismatches without force. A byte/int/float/double mismatch on the same variable name does not require force and does not error — Stata silently widens the variable to the larger storage type. That is usually harmless, but it is worth knowing it happened if you are tracking exact file size or precision.
• Duplicate observations after appending. If the same underlying records exist in both files — a common cause is re-appending a file you already appended once, or two “final” export files that overlap by a few rows — append has no way to detect or warn about the duplication; it is not a matching operation. Run duplicates report or isid on your key variable immediately after appending.

A pre-append checklist

1. Run describe on both datasets and compare variable names and storage types side by side.
2. Run label list on both, if either uses value labels, and check for conflicting definitions on shared variable names.
3. Append with generate() so the split can be verified afterward with tabulate.
4. Run duplicates report (or isid on your unique key) on the result before treating it as final.
5. Save the appended dataset under a new filename rather than overwriting either source file, so a mistake is recoverable.

Frequently asked questions

Does append change the dataset in memory immediately?

Yes — append, like most Stata data commands, modifies the dataset currently in memory in place; it does not create a new file automatically. Save the result explicitly with save under a new filename if you want to keep both the original and the appended version.

Can I append more than two datasets in one command?

Yes. append using file2.dta file3.dta file4.dta stacks all three onto the dataset in memory in one command, and generate() numbers them 1, 2, 3 in the order listed (0 stays reserved for whatever was already in memory).

What is the one-sentence difference between append and merge?

append adds more observations under the same variables (stacks rows); merge adds more variables for the same observations by matching on a key (joins columns). See append vs. merge above for the fuller version.

How do I undo a bad append?

Reload the original dataset from disk with use ..., clear and start over — append works on the dataset in memory, not a saved file, so nothing on disk is altered unless save was explicitly run afterward. Wrapping an exploratory append in preserve before running it and restore afterward avoids the reload entirely.

Related reading

For the row-stacking companion decision covered above, and for other Stata data-management commands, see CASRAI’s guides on the collapse command in Stata and running a t-test in Stata. Choosing Stata over the alternatives in the first place is covered in the SPSS vs. Stata comparison and R vs. Stata comparison. If the files being stacked need restructuring before or after, see tidy data rules for structuring research data. For the broader landscape of tools covered here, see the Research Tools & Software hub.