Incorrect syntax near ... - by Jim Russell

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 283413 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 6/19/2007 12:00:51 PM
Access Restriction Public


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
Sign in to post a comment.
Posted by Microsoft 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.

Posted by Jim Russell 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.)
Posted by Microsoft 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?

Posted by AaronBertrand 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?
Posted by Jim Russell 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...