How Many Ticks Does It Take DT To Load a DB Schema?

EdCarden

How Many Ticks (or seconds) Does It Take DT To Load a DB Schema?

I just timed it to find out myself and during normal business hours it takes Dependency Tracker more than 600 seconds (or greater than 10 minutes) to load a single DB Schema for a new Project.

While the previous version of DT may not have supported SQL Server 2008 R2 Reporting Services or SSIS integration it did at least run within a reasonable amount of time. I don’t recall exactly how long it took but I’m certain it wasn’t this long else I would have not purchased DT to begin with after the trial period.

Anyone else experience exceptional slow-downs in DT version 2.7 over a previous version? I have the same problem with SQL Prompt which is now to the point that its almost unusable.


NOTE: I actually took a 1 to 2 minutes longer to load the DB schema but I did not start timing the process until it had been running for a few minutes as I did not realize it was going to be this slow.

James B

Thanks for your post.
There's no easy answer to your question unfortunately - it sort of takes as long as it takes. The time will vary depending on the database and the server load, network connections, and several other factors. I'm not aware of it being obviously slower than earlier versions though.
How many objects do you have in your database?

You mentioned reporting services and SSIS - I didn't think dependency tracker supported these yet so they shouldn't make any difference?

As for Prompt being slow, it depends a little on how - is it slow starting up SSMS, or is it slow actually typing (characters appearing slowly etc)? If the latter, then upgrading your graphics card drivers can often help.

EdCarden

I wanted to revisit this now that it’s been over a year and there still has not been an update to Dependency Tracker.

I did some comparison and I can get a listing of every object of every type (plus some additional info beyond just the object type and name) using native SQL Queries in less then 1 second. Why then does Dependency Tracker take minutes to do this when its not doing anything more (that I can tell) other than getting all the object names and type and then placing them in a tree node like container/object?

What method is Dependency Tracker using to get the DB schema because it’s definitely not native SQL code executed thru an ADO/ADO.Net set of objects.

BTW- I’m asking because I want very much to use DT (especially since I paid for it) and I can't and I cannot find a logical reason for why the thing is as slow as it is at the point when it’s just getting DB schema info. I’d understand why it would take a while to parse through the Dependent objects after you have selected an object and added it to your project but Dependency Tracker is as slow loading the list of objects in the schema as it is when you have an object selected and are waiting for it to parse the dependent objects and list those. This is for just 1 level of dependency. I dare not try for any deeper a level then 1.

Also… Why does SDT (SQL Dependency Tracker) always return focus to the first node in the tree after you’ve selected and object under one of the trees nodes? For example after I have the DB Schema loaded and I expand the node within the tree that lists all the Stored Procedures, after I scroll down towards the end of the list of Stored Procedures and click on one the focus jumps back to the first stored procedure and so I have to scroll back down to where UI was at if I need to select another object. If there is a way to multi-select and avoid this please share that otherwise can this be added to the list of fixes.

Speaking of updates when can we expect an update to SDT which has not seen a major update since October 2011, almost 2 years ago?

James B

Thanks for posting back- we are actually working on some of the tools that we've unfortunately neglected a little. The next bout of work is targetting Doc and Data Generator, but Dependency Tracker is slated for some work later in October right now.
Most of the slowness will be down to the SQL Compare engine which SDT uses under the hood to examine and build up the model of the database it works with. We've made some improvements to the speed of SQL Compare recently, and the next build of SDT should inherit this, so it's likely that when we do release an update it should perform faster.

We've also set up a Uservoice for SDT here so you can start to add any suggestions in there which we can take into account down the line.