SQL Server Home
Incorrect syntax near ...
as Won't Fix
6/19/2007 12:00:51 PM
User(s) can reproduce this bug
When editing a SQL script, a bogus error "Incorrect syntax near..." is often encountered when the SQL syntax is checked (the blue check mark - parse.) The problem seems to occur when a line of the script is selected (highlighted); when the selection is moved, the parse succeeds.
Microsoft SQL Server Management Studio 9.00.2047.00
Microsoft Analysis Services Client Tools 2005.090.2047.00
Microsoft Data Access Components (MDAC) 2000.085.1117.00 (xpsp_sp2_rtm.040803-2158)
Microsoft MSXML 2.6 3.0 5.0 6.0
Microsoft Internet Explorer 6.0.2900.2180
Microsoft .NET Framework 2.0.50727.42
Operating System 5.1.2600
SQL Server 2005 - Enterprise Edition
Windows XP Professional
Operating System Language
Steps to Reproduce
Create a SQL (select) script
Select one complete line
Select PARSE (blue check icon to right of EXECUTE)
Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'where'.
Command(s) completed successfully.
to post a comment.
Please enter a comment.
on 10/8/2007 at 8:36 AM
Thank you for the elaboration. In SQL Server 2008, we are enabling Transact-SQL Intellisense that includes client side error flagging. (red squiggle feature as you've seen in Visual Studio or MS-Word).
The difference is that Yukon syntax checking requires a round trip to the server while Intellisense error flagging does not since it is 100% client side error checking operation.
Intellisense could provide functionality that you would need where there is no need to highlight a part of script or need to pay special attention to select a complete sentence to parse correctly by the server parser.
For the backward compatibility, we will leave the syntax checking button as it is (the blue check mark button) but we expect the utilization of the feature will be less and less with Intellisense.
on 9/28/2007 at 9:29 AM
Exactly as you suggest: ("where x = 5".) (It may well be documented that way somewhere.) So it is either necessary to select the entire script, select a complete SQL statement, or remove any selection before the parse or execute. It is rare to leave a complete SQL statement selected so the parse check will do something useful. This is particularly dangerous when selecting "Execute", as, at those rare times when the partial selection parses ok, the query reports complete when what was run was only a partial script. (I tripped over this on CREATE VIEW statements more than once, and wondered why my Create statement didn't seem to work.) I've gotten used to responding to any parse error by clicking anywhere in the script and trying again. It may be a "feature", but a confusing and not very useful one, IMHO. (E.g. I have never had the need to error check only one complete SQL statement, even using CTEs and multi-query T-SQL scripts.)
on 9/28/2007 at 8:49 AM
Thank you for reporting this issue. If is it still repro in your environment, can you please share the sample script so that our team can investigate it properly?
on 6/20/2007 at 7:22 AM
Do you mean if you highlight the second line of the following script, you get a "bogus" error?
SELECT * FROM sometable
WHERE x = 5
If that is not what you mean, could you post a script and the line you highlight so that others can try to reproduce?
on 6/19/2007 at 12:04 PM
This drove me crazy for the longest time. I often saw it after (un) commenting out a line. I suspected some bad character in the line, and would often recover by deleting the left margin and retabbing. Now I think I see what is going on...
to post a workaround.
Please enter a workaround.
© 2013 Microsoft