Error 102: Incorrect Syntax Near – Finding the Real Line in a Long Batch

Fix it now

Error 102’s published text is “Incorrect syntax near” followed by the token the parser was looking at when it gave up. That token is where it stopped, not where you went wrong. The mistake is almost always earlier: a missing comma, an unclosed quote, a reserved word used as a name, or a batch separator that reset the line numbering.

SET PARSEONLY ON;
GO
-- paste the batch here, then run
GO
SET PARSEONLY OFF;
GO

1. Count lines from the last GO, not from the top of the file. GO is a batch separator the client tool acts on, and the server numbers each batch from one.
2. Read the statement immediately before the reported position. A missing comma or an unterminated CASE in the previous statement is the single most common cause.
3. Check the token the message names. If it is a word like user, key, plan or function, it is reserved and needs square brackets: [user].
4. If the message is 105 rather than 102, a quotation mark was opened and never closed, and everything after it was swallowed as string text.
5. If the failing text is built at run time, print the generated string instead of executing it and parse that. 8180 means the generated statement could not be prepared, not that your outer code is wrong.

In SQL Server Management Studio, Ctrl+F5 parses the current batch without running it, which does the same job as SET PARSEONLY ON without editing the script.

If the batch parses, you are done. If it still fails, the next section explains what the parser is doing and why the position it reports drifts.

Why it happens

Running a batch happens in stages. The parser first checks that the text is grammatically valid T-SQL, knowing nothing about whether any of the tables or columns exist. Name resolution then binds identifiers to real objects, and only after that is a plan compiled and executed. Error 102 comes from the first stage, which is why nothing in the batch runs – not even the statements above the faulty one. A syntax error is fatal to the whole batch.

The parser has no idea what you meant. When it reads a token that cannot legally follow the previous one, it stops and quotes the token it was looking at. Leave a comma out of a select list and the parser happily reads the next column name as an alias for the previous one, then complains about the word after that. This is why the reported position is usually one token past the real fault, and occasionally a whole statement past it.

The neighbouring codes narrow it usefully. 156 is “Incorrect syntax near the keyword”, so the parser is telling you the offending token is a keyword where an identifier or expression belonged – which usually means a reserved word used as a name. 105 is “Unclosed quotation mark after the character string”, which is unambiguous. 4145 is an expression of non-Boolean type where a condition was expected, the classic single = in a WHERE or IF. 137 is “Must declare the scalar variable”, which is what you get when a variable is used in a batch after the GO that ended its scope.

Batch separators change the arithmetic in two ways at once. GO is not T-SQL: the client tool splits the script on it and sends each piece separately, so line numbers restart at every batch, and variables declared before a GO no longer exist after it. The first effect makes the reported line number misleading; the second produces 137. The same script usually manages both.

Full reference

Match the message to the mistake

Making the parser fail closer to the fault

• Terminate every statement with a semicolon. The parser then has a clear boundary and stops at the statement that is wrong rather than the next one.
• Keep batches short with regular GO separators, so a reported line number is close to something you can find.
• Indent consistently, and put each column of a long select list on its own line. A missing comma is visible immediately in that layout and invisible in a wrapped one.
• Parse before running, with Ctrl+F5 or SET PARSEONLY ON, so you iterate on syntax without side effects.
• Bracket every identifier that is not a plain word, rather than only the ones that have failed so far.

Dynamic SQL, properly

DECLARE @sql nvarchar(max) =
    N'SELECT * FROM dbo.Orders WHERE CustomerId = @cust AND OrderDate >= @from;';

PRINT @sql;   - read it before you run it

EXEC sys.sp_executesql
     @sql,
     N'@cust int, @from date',
     @cust = 42,
     @from = '2026-01-01';

Concatenating values into a statement is where most 102s in generated code come from: a value containing an apostrophe closes the literal, and the rest of your statement is read as string text. sp_executesql takes the parameters separately, so quoting stops being your problem, and it lets the plan be reused rather than compiled per value. It also removes the injection risk, which is the same fault seen from a security angle rather than a syntax one.

Why line numbers lie

Scripts that used to work

A script that ran for years and now fails on a new server has almost always met one of two changes. Either a word it uses as an identifier became reserved in a later release, which brackets fix permanently, or the database moved to a higher compatibility level that no longer tolerates a deprecated construct. Check SELECT name, compatibility_level FROM sys.databases; on both servers before assuming the script is at fault. Some constructs require a minimum compatibility level rather than only a minimum product version, so an upgraded server hosting a database still at an old level can reject syntax the same server accepts elsewhere.

None of this is a product problem

Error 102 behaves identically on Express and on Enterprise. No edition, patch, licence or configuration option changes how the parser reads a batch, and there is nothing to buy. If someone is selling you a fix for a syntax error, the thing being sold is a text editor.

Every code this article covers

Confirm the fix worked

1. Parse the whole script without executing it, with Ctrl+F5 or SET PARSEONLY ON, and confirm it reports success.
2. Run it against a test database and confirm the statements before the previously failing one now execute.
3. For dynamic SQL, print the generated string once more and confirm it parses on its own.
4. Confirm no 137 remains, which would mean a variable is still being used across a GO.
5. Run it on the target server as well as your own, in case a compatibility level or reserved word differs.

Questions people ask about this