Home Dashboard Directory Help
Search

Incorrect syntax near ... by Jim Russell


Status: 

Closed
 as Won't Fix Help for as Won't Fix


0
0
Sign in
to vote
Type: Bug
ID: 283413
Opened: 6/19/2007 12:00:51 PM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

SSMS
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
Details
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.

thanks!
-Eric
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.)
Thanks!
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?

thanks,
-Eric
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...
Sign in to post a workaround.