SQL Dependency Tracker feedback

Bart Read

Hi,


I still regularly use SQL Dependency Tracker to dig around database schemas, and have spent quite a bit of time in the tool today. In many ways it's great but it's also starting to show its age a bit, and I'd suggest could use a little bit of love to cure some of the irritations with using it.

Most of these suggestions shouldn't be too expensive to implement:

DOCKING AND PINNING

I understand why the decision was taken to make the Diagram Overview, Objects in Project, and Dependencies tool windows, well, not real tool windows. It was felt that docking didn't work well and confused/irritated users, especially when a window became accidentally undocked.

Whilst that may have been a valid concern in 2006 I'd argue that it is most definitely NOT a valid concern in 2015. For example, docking, floating, pinning, etc., in Visual Studio are an invaluable help to organise an otherwise complex project. Most of the annoyances have been worked out and people are USED to working with this kind of interface.

With a tool like Dependency Tracker its raison d'etre is the diagram, and what I need is as much screen real estate as possible to view the diagram. The ability to collapse tool windows, or drag them onto a second (or third) monitor would therefore be invaluable.

TOOLBARS

Similarly SQL Dependency Tracker has three toolbars - two immediately below the menu bar, and one below that (with buttons right-aligned) attached to the top of the GraphPanel. On a high resolution monitor (and how many people don't have one or more of those nowadays?) this wastes a lot of screen real estate at the top of the application window that would be better used as additional space for the diagram.

Can you collapse these down into a single toolbar, please?

OBJECT PROPERTIES/SQL SCRIPT WINDOW

The fact that this is a dialog box has always irked me. Granted it's not modal and it can be dragged onto a second monitor/resized easily enough, but it feels like a VS or SSMS style tool window. In fact it feels like two tool windows.

This really relates to my points above about docking/pinning: along with Diagram Overview, etc., please consider making these two functions into tool windows.

DEPENDENCIES WINDOW

My approach when using SDT is generally to pull all database objects into my project, hide everything (or pretty much everything), then selectively show things, often building up separate diagrams for each portion of the database I'm interested in (hey - how about multiple diagram support?), which I save out as separate projects.

The Search box in Objects in Project, and the Dependencies window beneath are invaluable tools to help me decide what's interesting, and what isn't. The problem with the Dependencies window is that, unlike the Objects in Project window, there aren't any actions associated with the nodes in the tree.

So, say I want to show all objects that reference the EMAIL_ADDRESS_MST table. At the moment what I have to do is:

- Select EMAIL_ADDRESS_MST, either in the diagram or in Objects in Project
- Double click on the first item in the Used By list to select it in Objects in Project
- In Objects in Project, check the checkbox next to the item
- Select EMAIL_ADDRESS_MST again
- Double click on the second item... etc.

What I really want to be able to do is multi-select all the items under Used By (which I can do), then right click and then click Show (or similar) on the context menu (which I can't do).

Short version: can we have the context actions that are available both on the diagram and in Objects in Project also available in the Dependencies window.

DEFAULT DISPLAY OPTIONS

Every time I create a new SDT project there are two options I invariably check:

View > Qualify > Object Names
View > Table Column Names

Could you either turn these on by default or make SDT remember what I selected last time round when I create a new project, please?

Databases I deal with generally fall into one of two categories:

- everything's in the dbo schema,
- everythings spread around, usually somewhat logically, between a fairly large number of function/area specific schemas.

Hence qualifying names pretty much always makes sense since there's no real cost if everything's in dbo anyway.

COLOURING OF OBJECTS IN DIAGRAM

Again, for historical reasons, SDT colours objects differently by database rather than by object type.

Whilst there are a variety of ways to colour objects (sometimes, for example, I do it by schema rather than object type), the choice of doing it by database is generally not the one I need. If you pick one way of doing it you're probably going to have an argument on your hands (although I'd argue that by database is by far the worst), so how about giving people the option of colouring objects:

- by type
- by schema
- by database

Or possibly even offer some combination where you could have an overall colour for the type, and a bar or stripe of colour for the schema?

Any of the above would be preferable to the current situation.

Ideally these would be options on the View menu (or a toolbar, or whatever) that make it easy to switch up after adding objects to your diagram.

The point of all this is that when you zoom out far enough that you can't read the text on nodes in the diagram, the colours provide a useful cue as to what's what, and enable you to navigate more quickly and easily.

=================

Hope these are all useful suggestions.


Thanks,

Eddie D

Hi Bart

Thank you your forum post and impressive list of suggestions for improving SQL Dependency Tracker.

I have submitted 3 new enhancement requests regarding the following headings:

Docking and pinning - DT662
Toolbars - DT-663
Dependencies Window - DT-664

I also updated the following existing enhancement requests for the following headings:
Colouring of objects in diagrams - DT-594, DT-486 and DT-178
Default display options - DT-453
Object properties / SQL Script window - DT-504

I will request that the Product Manager for SQL Dependency Tracker review the above enhancement request and post a comment to this forum post.

I cannot guarantee that the above requests will be successful or if approval is given, what future version of the SQL Dependency Tracker they will appear in.

Many Thanks
Eddie

Bart Read

Hi Eddie,


Thanks very much - appreciate it.

Couple of other things:

- It would be great if double-clicking a node opened up the source code,
- Similarly to the context menu Select > Connected Objects option, a Show > Connected Objects would be really helpful (or, better yet Show > Objects This Depends On, and Show > Objects That Depend On This).

(I know, give 'em an inch...)


Thanks!