Sharon Ben-Moshe is the founder of sqlfmt, a browser-based SQL formatter and validator with misspelled-keyword suggestions across PostgreSQL, MySQL, SQLite, SQL Server, and BigQuery.
SQL Server's "Incorrect syntax near" error means the T-SQL parser hit an unexpected token. Here are 7 common causes and how to fix each one.
Quick answer
SQL Server's "Incorrect syntax near" error (T-SQL error 102) fires when the parser hits a token it can't place at that point in the statement. The error names where the parser gave up — not where you made the mistake — so always look one or two tokens before the flagged one. Common fixes: remove trailing commas before FROM, add missing keywords like INTO or ON, wrap reserved words in square brackets, and close any unclosed string literals or parentheses.
Why does "Incorrect syntax near 'FROM'" appear when FROM is spelled correctly?
SQL Server flags FROM because that's where the parser gave up — not where the mistake is. A trailing comma in your SELECT list, a misspelled column expression, or a function missing a closing parenthesis just before FROM causes the parser to reach FROM in an unexpected state. Always scan the SELECT clause and any expressions above the FROM keyword first.
Is "Incorrect syntax near" the same as a runtime error?
No. "Incorrect syntax near" (error 102) is a parse-time error — SQL Server rejects the statement before running any of it. Runtime errors like division by zero or foreign key violations only appear after the query starts executing. Syntax errors must be fixed before the query can execute at all.
How do I see the line number of a T-SQL syntax error?
SQL Server Management Studio highlights the error line automatically when you run a query. You can also run SET PARSEONLY ON before your batch — this checks syntax and returns the error with a line number without executing any data changes. Azure Data Studio and the VS Code SQL Server extension display inline error markers as you type.
Can I use reserved words like "order" or "user" as column names in SQL Server?
Yes, but you must wrap them in square brackets: [order] and [user]. Most SQL style guides recommend avoiding reserved words as identifiers entirely — it keeps queries readable, portable, and immune to breakage when a word becomes reserved in a future SQL Server version.
What is SQL Server error number 102?
Error 102 is the SQL Server error code for "Incorrect syntax near". It is raised at severity 15 by the T-SQL parser when it encounters a token that violates the expected grammar at that position in the statement. Severity 15 means the error is always fatal for the batch — no part of the statement executes until the syntax is corrected.
Fix Google BigQuery's "Unrecognized name: column" error. Learn alias visibility rules across WHERE and QUALIFY, case sensitivity, and struct unnesting.
Fix PostgreSQL Error 57014: canceling statement due to statement_timeout. Learn how to tune query plans, configure timeouts per session, and avoid lock waits.
SQL Server's "Incorrect syntax near" error (error number 102) is the most common T-SQL syntax message you'll encounter. It fires when the T-SQL parser hits a token — a keyword, a symbol, or an identifier — that doesn't fit the expected grammar at that point in the statement.
Like PostgreSQL's "syntax error at or near", the token SQL Server names is where the parser gave up — not where you made the mistake. The real cause is almost always one or two tokens before the one that's flagged. If SQL Server says the error is "near 'FROM'", look at what comes immediately before FROM.
Here are the seven most common causes of this error in SQL Server, each with a broken and fixed SQL example.
What "Incorrect Syntax Near" Actually Means
Error 102 is raised by the T-SQL parser before any part of the statement runs. SQL Server reads your query left-to-right, token by token, following strict grammar rules for each statement type. The moment it finds a token that can't be placed at that position, it stops and reports that token in the error message.
The SQL Server error reference classifies error 102 as severity 15 — always fatal for the batch. No part of the statement executes. This is different from warnings (severity 0–10) or runtime errors that can sometimes be caught with TRY/CATCH. A severity-15 syntax error means nothing runs until the SQL is fixed.
1. Extra or Missing Comma
A trailing comma after the last column in a SELECT list — just before FROM — is the single most common cause of this error. It's an easy mistake when adding or removing columns: you delete the column but leave the comma, or you add a column at the end and forget the trailing comma is there. SQL Server reports the error on the FROM keyword itself, not on the comma.
Broken: trailing comma before FROM
SELECT customer_id, first_name, last_name,FROM customersWHERE active = 1;
Fixed: trailing comma removed
SELECT customer_id, first_name, last_nameFROM customersWHERE active = 1;
2. Misspelled T-SQL Keyword
A misspelled keyword like SELCT, UDPATE, or WHER is parsed as an identifier. Because an identifier in keyword position violates T-SQL grammar, the parser usually reports the error on the next valid token — not on the typo itself. Our guide to common SQL keyword typos covers the full list of misspellings that trip parsers across all major dialects. In T-SQL, pay particular attention to SELECT, UPDATE, DELETE, WHERE, and the JOIN variants — these are the most frequently mistyped.
Broken: misspelled keywords
SELCT order_id, totalFROM ordersWHER status = 'shipped';
Fixed: correct keyword spelling
SELECT order_id, totalFROM ordersWHERE status = 'shipped';
3. Reserved Word Used as an Identifier
T-SQL reserves hundreds of keywords. Using one — like USER, ORDER, TABLE, or KEY — as a column or table name without quoting it causes the parser to read it as the keyword and fail on whatever follows. The fix is to wrap the name in square brackets: [user], [order], [key]. Better long-term: rename the column to avoid the reserved word entirely, which keeps queries portable and readable.
Broken: reserved words used as column names
SELECT user, order, keyFROM transactions;
Fixed: reserved words wrapped in square brackets
SELECT [user], [order], [key]FROM transactions;
4. Unclosed String Literal or Parenthesis
A missing closing single quote turns everything that follows into part of the string — including keywords. SQL Server eventually hits a token it can't reconcile with "still inside a string" state and reports an error several lines below the actual problem. Missing closing parentheses have the same ripple effect, especially inside subqueries and function calls. When the flagged token is several lines from any obvious mistake, count your quotes and parentheses.
Broken: unclosed string literal
SELECT *FROM employeesWHERE department = 'Engineering AND active = 1;
Fixed: string literal closed
SELECT *FROM employeesWHERE department = 'Engineering' AND active = 1;
5. Missing Required Keyword
T-SQL syntax requires specific keywords in specific positions. The most commonly omitted ones are INTO after INSERT, ON after JOIN, and SET after UPDATE. Leaving them out causes the parser to report an error on the token immediately after where the missing keyword should appear — often a table name or column list that looks perfectly fine in isolation.
INSERT INTO orders (customer_id, total, created_at)VALUES (42, 199.99, GETDATE());
6. Wrong Clause Order
T-SQL enforces a strict clause order for SELECT statements: SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY. Putting HAVING before GROUP BY, placing ORDER BY before WHERE, or inserting WHERE after GROUP BY all produce "Incorrect syntax near" on the misplaced clause. This is easy to miss in long queries when you're adding or rearranging clauses.
Broken: HAVING before GROUP BY
SELECT department, COUNT(*) AS headcountFROM employeesHAVING COUNT(*) > 5GROUP BY department;
Fixed: GROUP BY before HAVING
SELECT department, COUNT(*) AS headcountFROM employeesGROUP BY departmentHAVING COUNT(*) > 5;
7. Syntax Not Supported at Your Compatibility Level
SQL Server adds new syntax features in each release, gated by the database's compatibility level. Functions like STRING_AGG() (level 130+), TRIM() (level 140+), and IIF() (level 110+) cause "Incorrect syntax near" if your database level is too low — SQL Server simply doesn't recognize them. Check your current level with SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME(). If you're on SQL Server 2016 or later and this error fires on a built-in function, raising the compatibility level is often the fix.
-- Fails if database compatibility level is 120 (SQL Server 2014) or lowerSELECT department, STRING_AGG(last_name, ', ') AS namesFROM employeesGROUP BY department;
Fix: raise the compatibility level (run as DBA)
-- Raise to 130 to unlock SQL Server 2016 syntax featuresALTER DATABASE YourDatabaseSET COMPATIBILITY_LEVEL = 130;-- VerifySELECT compatibility_levelFROM sys.databasesWHERE name = DB_NAME();
T-SQL Syntax Debugging Checklist
When you hit "Incorrect syntax near", work through this list in order:
Treat the flagged token as a signpost — look one or two tokens before it, not at it.
Count commas in your SELECT list — no comma should immediately precede FROM.
Count opening and closing single quotes — every string literal must be closed on the same line (or use N'' for Unicode strings).
Count parentheses — every open paren in function calls and subqueries needs a matching close.
Verify clause order: SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY.
Wrap any column or table name that is a T-SQL reserved word in square brackets: [user], [order], [key].
If the error is on a function like STRING_AGG or IIF, check your database compatibility level — some syntax requires level 110, 130, or 140.
Wrapping Up
"Incorrect syntax near" always traces back to one of a small set of structural mistakes: an extra comma, a missing keyword, an unbracketed reserved word, an unclosed literal, wrong clause order, or a function unavailable at your compatibility level. Work backward from the flagged token and you'll find the cause quickly. sqlfmt formats and validates T-SQL in your browser, flagging misspelled keywords and common structural issues before you run the query — a useful sanity check when an error message isn't pointing where you expect.