The primary target customer for SQL Editor is the database developer who is dealing with complex or unfamiliar Microsoft SQL Server databases.  Using SQL Editor, the developer can work in a way which would otherwise require an intimate knowledge of the databases involved.
 

When following a train of thought, a developer can be more productive if all the information they need is immediately to hand.  If they have to spend time searching for information, that train of though can easily be lost.  This is one reason why familiarity with a system makes for more efficient development: less research is required.

SQL Editor was conceived to address these issues.  It aims to give the developer the shortest and most intuitive path from wanting to know to knowing, from wanting to do to doing.
 

This is roughly equivalent to using the Find in Files feature of Visual Studio.NET to search for files in a solution.  Important enough to warrant the Ctrl-Shift-F shortcut key in VS.NET, and yet there is no equivalent feature in the standard database tools.

Click here for an example.

Object hierarchies
When one object makes references to others, the referenced objects can be shown as subordinate nodes in the explorer tree.

A developer will frequently refer to the definition of a table when designing a stored procedure to manage that table.  The Object Hierarchy feature of SQL Editor allows the user to easily move between stored procedure and table without having to follow a tedious navigation process.

Click here for an example.

Object History Browser
When a user makes changes to object definitions, SQL Editor can save the new definitions to a history file.  When this Auto Scripting feature is enabled, SQL Editor allows the user to view previous versions of the objects they have compiled, and compare two versions of an object using a file compare program such as WinDiff.

This feature can be useful when analysing changes in system behaviour, or retrieving lost code.
 

• SQL 2005 support (excludes synonyms, assemblies, database triggers)
• Multiple simultaneous server connections
• Real-time colour coding
• Multiple user contexts
• Object History Browser
• Object permissions and column permissions manager dialogs

There are a few tools on the market which aim to graphically depict SQL statement structures.  While these tools have their uses, graphical representation necessarily leads to simplification and can result in a loss of control over detailed issues often required by an experienced developer.  SQL Editor is aimed at the experienced developer, and always displays the fundamental SQL definition of an object.
 

David uses SQL Editor to search for objects containing "Customers".  He finds four stored procedures, two views and the table itself.  These objects are displayed together in a search results folder.  Clicking on each of the objects in turn, David can easily view and amend them as necessary.

He runs similar searches to look for references to the two views, and finds that six other stored procedures, all apparently involved in Customer reporting, use the views.  His previous search results remain visible, so he can easily backtrack to check he has covered all the objects he should.

Because all the information is easily available, David can spend more time getting on with the work he enjoys: fixing code.

How would this be done without SQL Editor?
David could have used one of two conventional approaches:

If he is lucky enough to be familiar with the system, he might use this knowledge to help him determine which objects should be modified.  But even an experienced developer is likely to miss something using this approach in a complex system.

Alternatively, he could script the entire database, and use a text editor to search for references to the Customers table.  Having discovered the views, he would then have to finish searching the script for Customer references, go back to the top and search for references to each of the views in turn.

David would also have briefly considered how up-to-date the documentation might be, and wondered if he could rely on it to help make his changes.  More than likely, he would discount that approach as too risky.

In summary, by using SQL Editor, David will save himself time and be more accurate in his work.
 

Using SQL Editor's Object Hierarchy feature, Maria is easily able to find her way around the system.  She selects the controlling stored procedure and selects Expand All from its context menu.  The full process structure is depicted in a tree structure which is easily understood.

She can easily get a printable version of the structure by using the Tree | Preview Structure... menu command.

How would this be done without SQL Editor?
To understand the process, Maria would probably have to diagram it.  This would involve looking at each stored procedure in turn, and determining which stored procedures it calls.  Depending on the complexity of the batch process, this could take quite a while.

In summary, using SQL Editor, Maria can obtain an up-to-date process diagram in seconds.  This helps her understand the system better and make her changes more efficiently.