Stata Error r(198): Every Cause of 'Invalid Syntax' and How to Fix It

You’ve been staring at this line of code for five minutes. It looks perfect. You’ve checked every parenthesis, every comma, every variable name. You run it again.

invalid syntax
r(198);

Error r(198) means Stata cannot parse your command. The syntax is invalid — but the reason why is often invisible. This guide covers every documented cause of r(198) and shows you exactly how to fix each one.

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

Quick Answer

Error r(198) means “invalid syntax.” The most common causes are:

1. Invisible characters from copy-pasting code (PDFs, Word, websites)
2. Smart quotes (“ ”) instead of straight quotes (" ")
3. Missing comma before options
4. Wrong macro delimiters
5. Tab characters or byte-order marks in your .do file

The fastest fix: retype the offending line by hand in the Stata command window. If the retyped version works, invisible characters were the problem.

Cause 1: Invisible Characters from Copy-Paste

This is the single most common cause of r(198), and the hardest to diagnose because the problem is literally invisible. When you copy code from a PDF, a Word document, a website, an email, or even a Slack message, the text often carries hidden characters: zero-width spaces (U+200B), non-breaking spaces (U+00A0), zero-width joiners, or other Unicode control characters.

These characters look like normal spaces or are completely invisible, but Stata’s parser chokes on them.

1* This line looks identical to valid Stata code
2* but contains a zero-width space after "regress"
3regress​ wage education experience, robust

invalid syntax
r(198);

How to diagnose

Open your .do file in a text editor that shows invisible characters. In VS Code, turn on “Render Whitespace: All” (editor.renderWhitespace). In Sublime Text, use View → Indentation → Convert to Spaces to reveal non-standard whitespace.

The fix

Retype the line by hand. Don’t copy it — type every character from scratch in the Stata command window or do-file editor. If the retyped version works, you know invisible characters were the problem.

Cause 2: Smart Quotes Instead of Straight Quotes

Word processors, Google Docs, and many email clients automatically convert straight quotes (") into “smart” or “curly” quotes. Stata only accepts straight quotes.

* Smart/curly quotes — WRONG
gen highwage = (wage > 50000)
label variable highwage “High wage indicator”

* Straight quotes — CORRECT
gen highwage = (wage > 50000)
label variable highwage "High wage indicator"

The difference is nearly impossible to see in most fonts. The left example uses Unicode characters U+201C and U+201D (left and right double quotation marks). Stata needs U+0022 (the plain ASCII double quote).

Cause 3: Missing Comma Before Options

In Stata, options come after a comma. Forget the comma and the option becomes part of the variable list, causing a syntax error.

regress wage education experience robust

regress wage education experience, robust

variable robust not found
r(111);

Notice that forgetting the comma sometimes produces r(111) instead of r(198), because Stata interprets the option name as a variable. But with certain options or command structures, you get r(198) directly.

1* All of these need a comma before the option
2regress wage education, vce(cluster state_id)    "stata-comment">// correct
3regress wage education vce(cluster state_id)     "stata-comment">// r(198)
4
5merge 1:1 id using data2, nogenerate             "stata-comment">// correct
6merge 1:1 id using data2 nogenerate              "stata-comment">// r(198)
7
8graph twoway scatter wage education, title("Wages") "stata-comment">// correct
9graph twoway scatter wage education title("Wages")  "stata-comment">// r(198)

Cause 4: Wrong Macro Delimiters

Stata uses a unique syntax for local macros: a left single quote (backtick) to open and a right single quote (apostrophe) to close. Getting either one wrong produces r(198).

local controls "education experience tenure"
* Using regular quotes — WRONG
regress wage 'controls', robust
* Using two apostrophes — WRONG
regress wage 'controls', robust

local controls "education experience tenure"
* Backtick + apostrophe — CORRECT
regress wage `controls', robust

The opening delimiter is the backtick character (U+0060), typically on the key left of the 1 key on US keyboards. The closing delimiter is the standard apostrophe (U+0027). Using two apostrophes or two backticks both fail.

Cause 5: Incorrect #delimit Usage

The #delimit ; command changes Stata’s command delimiter from carriage return to semicolon. If you forget to reset it, or if your .do file mixes delimited and non-delimited sections, you’ll get r(198) on lines that look perfectly valid.

1#delimit ;
2regress wage
3    education
4    experience
5    tenure,
6    robust ;
7
8* Forgot to reset delimit — now ALL subsequent commands need a ;
9summarize wage
10// ^ This now produces r(198) because Stata is waiting for a ;
11
12#delimit cr     "stata-comment">// Reset back to carriage return
13summarize wage  "stata-comment">// Now this works

1* Use /// for multi-line commands — much safer
2regress wage "stata-comment">///
3    education "stata-comment">///
4    experience "stata-comment">///
5    tenure, "stata-comment">///
6    robust

Cause 6: Line Continuation (///) Errors

The /// continuation marker tells Stata that the command continues on the next line. But there are two common mistakes:

1* ERROR 1: No space before ///
2regress wage education"stata-comment">///   // r(198) — needs space before ///
3regress wage education "stata-comment">///  // correct
4
5* ERROR 2: Characters after ///
6regress wage education "stata-comment">/// these are not comments
7regress wage education "stata-comment">/// // this is also wrong
8regress wage education "stata-comment">///  // this IS a valid comment (space between)

Stata requires at least one space before ///. Anything after /// on the same line is treated as a comment, but only if there’s a space. Without the space, Stata tries to parse it as part of the command.

Cause 7: if vs in Confusion

Stata’s if qualifier (for subsetting) uses a different syntax than the programmingif command. Mixing them up causes r(198).

* Trying to use programming if syntax
if gender == "female" {
    summarize wage
}
* This works but is DIFFERENT from:
summarize wage if gender == "female"

* The if qualifier — what you usually want
summarize wage if gender == "female"
* The programming if — for flow control
if _N > 100 {
    display "Large sample"
}

The if qualifier goes after the command and variable list. The programming ifgoes at the start of a line and requires curly braces. Using the wrong one in the wrong place gives r(198).

Cause 8: Parentheses in Option Syntax

Some options use parentheses, some don’t. Getting the parentheses wrong — or using brackets instead — causes r(198).

* Square brackets — WRONG
regress wage education, vce[cluster state_id]
* Missing inner parentheses — WRONG
regress wage education, vce(cluster)
* Extra parentheses — WRONG
regress wage education, (robust)

* Correct: parentheses with full specification
regress wage education, vce(cluster state_id)
* Correct: simple option without parens
regress wage education, robust
* Correct: option with proper parens
regress wage education, absorb(firm_id)

Cause 9: Version-Specific Syntax

Commands introduced in newer Stata versions produce r(198) if you run them on an older version. The most common cases:

1* frames — requires Stata 16+
2frame create myframe   "stata-comment">// r(198) on Stata 15
3
4* collect/table — requires Stata 17+
5collect create mytable  "stata-comment">// r(198) on Stata 16
6
7* dtable — requires Stata 18+
8dtable wage education   "stata-comment">// r(198) on Stata 17
9
10* Check your version:
11version

version 18.0

Cause 10: Byte-Order Marks (BOM) in .do Files

Some text editors (notably Notepad on Windows) save files with a byte-order mark — invisible bytes at the very beginning of the file. Stata cannot parse the BOM and throws r(198) on the first line of your .do file.

If r(198) occurs on the very first command in your .do file, and that command works fine when typed directly in the command window, BOM is likely the culprit.

The fix

In VS Code: click the encoding indicator in the bottom status bar → select “Save with Encoding” → choose “UTF-8” (without BOM). In Notepad++: Encoding → Convert to UTF-8 (not UTF-8 BOM).

Cause 11: Tab Characters

While Stata generally handles tabs, they can cause r(198) in specific contexts — particularly inside strings, in #delimit mode, or when mixed with continuation lines.

label variable wage	"Hourly wage"
* The gap above is a tab, not spaces

label variable wage "Hourly wage"
* Use spaces consistently in .do files

Cause 12: Unicode Issues from Non-English Systems

If your operating system locale uses non-ASCII characters (Chinese, Arabic, Cyrillic), file paths and variable names containing these characters can trigger r(198). Stata’s Unicode support improved in version 14+, but edge cases remain.

1* This may fail depending on your system encoding
2use "/Users/données/analyse.dta"
3
4* Safer: use ASCII-only paths
5use "/Users/data/analysis.dta"

Cause 13: Mismatched or Nested Quotes

Stata uses compound double quotes (“ ” as `" "’) for strings containing quotes. Getting these wrong causes r(198).

* Nested regular quotes — WRONG
local mystring "She said "hello" today"
* Unmatched quote — WRONG
display "This is unfinished

* Compound quotes for nesting
local mystring `"She said "hello" today"'
* Properly closed
display "This is finished"

Cause 14: Factor Variable Notation Errors

Factor variable prefixes (i., c., ibn.) have strict syntax rules. Common mistakes:

1* Space between prefix and variable — WRONG
2regress wage i. industry, robust     "stata-comment">// r(198)
3
4* Correct — no space
5regress wage i.industry, robust
6
7* Wrong prefix format — WRONG
8regress wage i(industry), robust     "stata-comment">// r(198)
9
10* Interaction with wrong operator — WRONG
11regress wage education*experience    "stata-comment">// r(198)
12
13* Correct interaction notation
14regress wage c.education#c.experience

Cause 15: Commands Run as Prefix (or Vice Versa)

Some Stata keywords are command prefixes, not standalone commands. Running them alone — or running a standalone command as a prefix — triggers r(198).

* by is a prefix, not a command
by state_id, sort: wage
* quietly needs a command after it
quietly

* Correct prefix usage
bysort state_id: summarize wage
* quietly modifies a command
quietly regress wage education

Debugging Checklist

When you hit r(198), work through this list in order:

1. Retype the line by hand. If it works when retyped, invisible characters were the problem.
2. Check for smart quotes. Search your .do file for “ and ” and replace with ".
3. Verify the comma. Make sure options are separated from the variable list by a comma.
4. Check macro delimiters. Local macros use backtick-apostrophe: `var’.
5. Check #delimit state. If using #delimit ;, make sure every command ends with ;.
6. Check your Stata version. Run version and verify the command exists in your version.
7. Run one line at a time. Paste each line individually into the command window to find the exact offending line.

FAQ

What does r(198) mean in Stata?

Error r(198) means Stata could not parse your command. The syntax is invalid — either a typo, invisible character, wrong delimiter, or misplaced option. It is not a data error — your dataset is unaffected.

How do I fix invalid syntax in Stata?

First identify the exact line causing the error by running your do-file line by line. The most common fixes are: replace smart quotes with straight quotes, add a comma before options, fix macro delimiters (backtick + apostrophe), and remove invisible characters by retyping the line.

Why does Stata say invalid syntax when my code looks correct?

Invisible characters are the most common cause. Code copied from PDFs, Word documents, or websites often contains zero-width spaces, non-breaking spaces, or smart quotes that look identical to valid characters but Stata cannot parse. Retype the line by hand to test.

Does r(198) mean my data is corrupted?

No. Error r(198) is purely a syntax error in your command. Your dataset is completely fine. The problem is in how the command is written, not in the data it operates on.