I've been using EMS SQL Manager for SQL Server (v 2.1 Lite) with varying success for a few weeks now. It's a great tool for an unbeatable price, but my conclusion so far is that EMS doesn't quite get it. Or maybe I just don't get EMS:
For instance - there are (at least) 3 types of editors. Why 3? They're all slightly different:
The Script Editor:
- it comes with a handy left-side Script Explorer, allowing quick access to code within a large script file,
- it'll show output from stuff like PRINT 'foo' in a separate result pannel,
- but it doesn't give you a result set for, say , SELECT * FROM Foo - it just tells you in a message box that the query executed (unless you check the box that says "Don't show this message", in which case the message is displayed only in the status bar).
- It has no editing toolbar/navbar.
- it allows you to execute statements like SELECT * FROM Foo or INSERT INTO FOO SELECT * FROM Bar,
- but does NOT support statements like PRINT 'foo' - it simply ignores them.
- Unlike the other editors, the SQL Editor allows "sub-tabs"; additional queries within the same editor.
- It has an Editing toolbar/navbar, listing Find, Load, Save and Save All. A Replace feature IS available in the editor, but only from the context menu.
- This allows you to edit stored procs and UDFs
- It has a tab each for the Procedure/Function, Parameters, Dependencies, Description and DDL.
- As far as I can tell the only difference between the Procedure/Function and the DDL tabs is that the DDL tab is read-only.
- There is no edit toolbar/navbar
- There is an Object selector, which acts like a navigation tool to open a different stored proc/view. If you have made changes in the procedure and then select another, you're first asked "xxx has been changed. Do you wish to save it right now?" with the options Yes, No and Cancel. If you select No, you're asked again Discard changes? with a Yes and No option. -Superfluously superfluous.
- No central Edit menu. Yes, an Editor without an Edit menu. The user is left to discover on his/her own features like:
- Ctrl+Shift+I (indent (but only if the text is selected),
- Ctrl+Shift+U (unindent),
- Ctrl+Shift+L ("line-select" mode)
- Ctrl+Shift+C ("column-select" mode)
- Ctrl+Shift+N ("normal select" mode)
- Ctrl+F (find - arguably this IS listed in the context menu, and there's a tool menu item in the SQL editor)
- Ctrl+R (find/replace - this too is listed in the context menu, but nowhere else)
- and a whole slew of other common Edit functions that I have yet to stumble across
- There's a separate Config screen for the Editor Options (different from the Editor Options within the Environment Options config)
- There's no intellisense for parameters (@foo).
- There is no public disclosure of requests, feedback, or bugs, a la that of JetBrains. This means that every user operates in a vacuum between EMS and the user, with no ability to learn more about the product from other users. I can only imagine that this means the support personnel at EMS therefore has to field the same complaints/questions over and over.
- There seems to have been a lack of testing before shipping - I keep encountering bugs that shouldn't be that hard to reproduce (like actually using the Save Settings feature).
So why do I use the tool, if it sucks this bad? Well, it doesn't really.
I have 5 reasons, primarily, for why I use EMS SQL Manager Lite:
- Intellisense. Why MS doesn't have intellisense in their SQL tools is beyond me. EMS' intellisense feature works well (with the exception of the parameters).
- Keyboard templates. These work similar to Live Templates in ReSharper. Essentially they're SQL snippets that you can insert by typing a specific text.
- Database object hyperlinks. Within a stored procedure it is easy (Ctrl+Click) to navigate to the definition of any object used in the code.
- It's free! You get a lot for nothing, which makes it that much easier to make it the standard tool for SQL editing throughout your organization.
- Save Settings. Saving your settings and sharing the resulting registry files with other developers on your project can make it simpler to reuse and standardize code.
There are other reasons as well (tabs in DB Explorer, automatic updates, choice of MDI or windows, etc, etc), but this is getting too long already...