Adding intellisense and refactoring to the T-SQL editor

One of the features I would like to see in our tools for SQL Server is a T-SQL language service. This would give customers features like intellisense, text completion, refactoring (e.g. renaming a table everywhere at once), error highlighting (as in Word’s red squiggly underlining), and host of other features that C# and Visual Basic have in Visual Studio 2005. Unfortunately, implementing a language service for T-SQL requires solving some difficult problems. Below I discuss the implementation problems and some ideas I have for fixing them. It would be great to hear your thoughts too.


T-SQL has a large and complex syntax with features that make parsing it with conventional parsers difficult. Language constructs like selectfrom … make intellisense hard to do since you need to have the from-clause written before you can offer intellisense on the select-clause yet T-SQL encourages people to write the select clause first. The only viable solution, I can think of, is when the user has typed select to automatically add the from-clause and move the cursor there. Perhaps in a future version of T-SQL we could support a fromselect … syntax which would also be a more natural syntax. Moving users to the from-clause may be too intrusive, what do you think?


To allow intellisense and refactoring work well, an accurate semantic analysis of the T-SQL script needs to take place. However, T-SQL frequently refers to other databases and some parsing depends on server settings (e.g. ANSI nulls). To provide enough information for the language service to work correctly and efficiently, we will need to cache server and database related information locally in database models. Since we need to do this, it makes sense to build the language service on the modeling engine in Microsoft’s new graphical DSL framework. Some changes will be required but the modeling framework is close to a good AST framework and so it makes sense to reuse it.


Batch parsers are fast but for large files, they are not fast enough to support character at a time reparsing. There are ways to disguise some of this delay but ultimately intellisense becomes too slow to be usable and frustrates users. In addition, batch parsers require heavy modification to minimize the amount of change events from the object model they expose to tools. For example, imagine an explorer that lets you explore your T-SQL code like class view lets you explore your C# code. It would be unacceptable if at every key stroke all of the tables defined in the file disappeared and then reappeared in the explorer. Thus, a best practice for language services is to base them on a new incremental parser for the language. This involves a lot of work that we could use to improve other aspects of the T-SQL development experience. Is intellisense, refactoring, etc worth it?


A language service needs to handle errors robustly since users may be partly through typing a statement but intellisense etc should continue to work well. Batch parsers (i.e. compiler parsers) must handle large amounts of correct text quickly. Batch parsers are optimized for throughput not error recovery so adapting them for a language service is challenging. Adding to the complexity, in SQL Server 2005, T-SQL may contain imbedded XQuery expressions. For a language service parser, I would normally recommend either a recursive descent parser (for speed and great error recovery options) or an incremental GLR parser (for minimal reparsing costs, good error recovery and good ambiguity handling). However, the need to deal with multiple languages makes an incremental GLR parser the best choice. I particularly like the incremental GLR parser in Tim A. Wagner’s thesis when paired with the incremental semantic analysis in William Maddox’s thesis.


One of the nice things in Visual Studio 2005 is the managed language service (the wonderful new Visual Studio XML editor uses it). Provided you have a good incremental parser and an almost LR language then it is easy to build a great language service. It would be great to combine our graphical DSL framework, the managed language service and an incremental GLR parser framework to create a framework for building textual DSLs. This would allow people to create their own special purpose languages complete with intellisense, text completion, etc.


This posting is provided "AS IS" with no warranties, and confers no rights.


Comments (18)

  1. Travis Owens says:

    I was actually expecting SQL 2005’s manager to support these features. So I guess it’s not, well I’m honestly dissapointed.

    Currently I use VS2003 to write my SQL and DTS stuff because there is decent highlighting in there and some bare bone support. I despise using SQL server’s built in management because it’s not even up to pare with Notepad, at least notepad has a search & a replace feature.

    IMHO SQL 2000 management lacks any respectable support when it comes to writing SQL or DTS.

  2. Rommel Abesames says:

    1) this just reinforces that SQL/T-SQL is a badly designed language

    2) already supports some form of "intellisense" for MS SQL Server (among other dbmss). so does

    3) while there is value in a clean and elegant solution, even a limited and crude (relatively) solution is sorely needed and way overdue for MS T-SQL tools. Even if you have to tie it to a specific T-SQL version and/or support only limited languange constructs it would still be very useful.

  3. I have to agree with Rommel’s comment "while there is value in a clean and elegant solution, even a limited and crude (relatively) solution is sorely needed and way overdue for MS T-SQL tools." Internally, several people have built T-SQL intellisense and people here seem happy enough to use these imperfect tools. However our usability testing shows that people have high quality expectations of T-SQL intellisense in a Microsoft product. This makes it hard for us organizationaly to deliver something. Even though anything would be better.

  4. Simon says:

    One argument is that if a compiler can understand all the constructs, aliases, schemas or not, prefixes or not.

    The solutions I have seen often suffer with the number of objects to hold information about. I would be interested to know how many objects the intellisense for say c# is designed to cope with (or tested against). Often the reason for the slowness is due to not understanding context properly, which is part of the problem with SQL with it being very flexible.

    Then there is the issue of dynamic SQL, how do you solve that one easily?

    You then have the issue of defferred object creation so objects might not exist at design time. I wish this was configurable (with out using schema binding)

  5. Ashton says:

    There are several 3rd party editors our there that do a fairly good job at providing Intellisense (one happens to be mine ApexSQL Edit 🙂 Providing Intellisense is difficult in a language like SQL because of the issues you mention and also because of the context since you can have aliases, or not, subqueries, or not, etc. One way we handle the select clause issue is to allow the user to predefine aliases for commonly used tables so that when a user types a specific alias in the select clause, the IDE looks up the alias and shows the appropriate columns.

    There are also other tools out there that do a decent job of Intellisense for SQL, although none of them are perfect and handle every case because of the difficulties mentioned.

    However, I don’t think it’s the problem with TSQL as much as SQL. TSQL is a very structured languages, it’s SQL itself that allows for essentially free form flow. For example, you can have the following

    select 1 "Column", 1 as "Column", "Column"=1

    from Orders, Northwind.dbo.Orders, dbo.Orders, Orders ord

    All of which are the same in the select and from clauses, so trying to parse it becomes a complex task.

  6. Dave Russell says:

    It looks to me like MS are going away from "most" developers having to hand-code TSQL anyway. They’re introducing LINQ/DLINQ which gives you language constructs that ultimately map to SQL and, supposedly, optimised SQL much better than you or I would imagine.

    These do have intellisense, so TSQL intellisense suddenly becomes much less important in their eyes…… I wouldn’t expect it in SQL-Server-Next either.

  7. Rommel Abesames says:

    "Internally, several people have built T-SQL intellisense and people here seem happy enough to use these imperfect tools"

    Why not release it either unofficially, or as a hidden unsupported feature (registry setting dependent)? (e.g. MS SQL Server PowerToys). Or part of MS SQL Server Resource Kit. Or something…just get it out already. 5 years ago =)

  8. Someone mentioned ‘sqlprompt’ — its actually called PromptSQL and uses low-level system hooks to intercept keystrokes in Query Analyzer, VS.NET and SSMS, combined with the ANTLR parser to give SQL Intellisense:

  9. Joe Salvatore says:

    I am familiar with Ashton’s work with ApexSQL Edit and it is quite elegant.

    I would like to add that some of the difficulties surrounding intellisense center on where the object caching occurs. If I am correct, SQL uses disk based caching of objects and other products are using memory. This impacts both the way in which intellisense is working and the user experience in using the intellisense (slow – fast, cumbersome – easy).

    I do think that Rommel is right in that our expectation of the great Wizard of MS would have been to have elegantly conquered SQL intellisense quite some time ago.

    Come on… Dorothy needs to get home… presumably to work on other higher level things than TSQL object sytanx…

  10. Appdev says:

    Another one I’ve found and used a bit lately is SqlAssist (add-in to Visual Studio). Seems quite nice, as it supports some fancy features like templates, pretty formatting, running a script on several DBs at once, etc. Site says it is still in beta (alpha?), but seems pretty powerful for an early product to me. Anyway, thought some of


  11. Robert Hyatt says:

    Since internally SQL Server uses the Language Processing and Execution subsystem to parse TSQL before compilation, why not publish an API to this subsystem and let developers extend the IDE using the native parser rather than hand-roll an incomplete parser? Not too many hits on Google about this subsystem but there has to be some way to programatically access it?

  12. SimonS says:

    Looking back it was a long time ago that Euan G and Patrick Conlan came to the UK and showed us Yukon…

  13. SimonS says:

    Looking back it was a long time ago that Euan G and Patrick Conlan came to the UK and showed us Yukon…

  14. Looking back it was a long time ago that Euan G and Patrick Conlan came to the UK and showed us Yukon…

  15. Paul says:

    Not looking for Intellisense for the "select" command necessarily, but how about Intellisense for the functions that are available?  Anyone got something that works in TSQL???

  16. Jason Jack says:

    Recently I ve been trying PragmaSQL it is like its name suggest a pragmatic approach to T-SQL development. You can check it out from

Skip to main content