Comments
Sort by recent activity
Here's another example query I would love to ask the underlying data: which views out of 200+ involve tables A, B and X?
That would allow me to possibly reuse a view rather than end up re-inventing the wheel.
- alphadog
PS: I am available for consultantion for a small fee... [image] / comments
Here's another example query I would love to ask the underlying data: which views out of 200+ involve tables A, B and X?
That would allow me to possibly reuse a view rather than end up re-inventing...
Ah, yes. Very faint grey. Missed it. Thanks. / comments
Ah, yes. Very faint grey. Missed it. Thanks.
Using the mousewheel is currently the "best thing" for zoom in, but the app's visuals beg for a way to use the magnify icon to allow for rubberbanding an area to zoom into, rather than just arbitrary steps. Zooming out could be done via rubberbanding in the Diagram Overview.
And, I mean that as a long-time developer who totally understands that you can only do so much with so little time! Awesome product, BTW. I was going to develop one myself, but now why bother... [image]
- alphadog / comments
Using the mousewheel is currently the "best thing" for zoom in, but the app's visuals beg for a way to use the magnify icon to allow for rubberbanding an area to zoom into, rather than just arbitra...
Agreed.
I find the mouse scroll faster for zoom in/out than magnify glass icons.
- alphadog / comments
Agreed.
I find the mouse scroll faster for zoom in/out than magnify glass icons.
- alphadog
No need to apologize. It is a beta after all. [image] / comments
No need to apologize. It is a beta after all.
Dan:
I would use RGDT mainly for:
- imapct analysis
- change auditing (although, darn, it won't tell you who did the change so you can hunt them down in cold blood!)
- sourcing data/images for adding to automated development docs
I think the reason most beta testers dump a whole db into your app is a function of:
a) Lack of initial guidance in the beta process. You might consider some sort of in-app introductory page for first-time users.
b) UI design for staring a project plus typical user laziness. People will likelier just "dump all" then find what they need, rather than pick out first. I know I did. If the UI instead asked for a single starter object, it might be a different outcome in user experience.
- alphadog / comments
Dan:
I would use RGDT mainly for:
- imapct analysis
- change auditing (although, darn, it won't tell you who did the change so you can hunt them down in cold blood!)
- sourcing data/images for addi...
Alex:
You'll have to forgive me as I have not used SQL Compare. I use a different product that is similar from another vendor. I'll assume it generally does the same thing, which is to find textual differences between DDL statements for same-name objects.
SQL Comapre and RGDT are complimentary, but not exactly similar, in the data they collect. However, sematically, the data is very different. In the former, it's raw textual diffs catching more variety of changes, in the latter you get explicitly-stated relationships between objects, but only that. The former may catch differences in the FROM statement, the latter will directly tell you that a view that used to include tableA does not do so anymore.
So, if I drop a table in a view in a database used by four business-line apps, it's (theoretically) easier for me to determine that appB will fail by rummaging through explicit relationship data (especially automatically) rather than "semi-structured" textual diffs.
My "wet dream app" would be to marry the dependency checking in RGDT (sans visuals; command-line outputs) to track all the way into .NET source code and make it part of an automated build/test process here at work.
Does that make sense? I may not have explained it correctly. / comments
Alex:
You'll have to forgive me as I have not used SQL Compare. I use a different product that is similar from another vendor. I'll assume it generally does the same thing, which is to find textual...
Agreed.
The real gold in this software is the data. I don't know if RG thinks that the visuals are the meat, but just in case, I'll re-iterate that the visuals are the sizzle, but the steak is the data. The sizzle doesn't last; it's a good steak that keeps you coming back to the restaurant. [image]
I would caution that if RG's backlog of tasks on this software isn't at least partly focused on expanding and exposing the data, RG may be heading in the wrong direction with the product since developers will appreciate the graphs but will love many of the more silent things (query interface to data, expanded depth of dependency checking, command-line control and export, linking into other development tools, etc...) being mentioned in this forum. I don't mean this as negative criticism, since it is alreayd a great product; I'm just trying to think "what do I expect next?".
- alphadog / comments
Agreed.
The real gold in this software is the data. I don't know if RG thinks that the visuals are the meat, but just in case, I'll re-iterate that the visuals are the sizzle, but the steak is the ...
Agreed.
One of the main reasons I'd purchase such a tool is that I'd like to be able to track what would be affected by a column drop, name change, split, etc...
Also, differenciating (maybe as simple as color-coding) between a column being involved in a SELECT clause versus a column in a JOIN would be even better.
- alphadog / comments
Agreed.
One of the main reasons I'd purchase such a tool is that I'd like to be able to track what would be affected by a column drop, name change, split, etc...
Also, differenciating (maybe as sim...
There is a problem with looking at the table-level to understand column dependencies. For example, assume I have TableA, used in three views A, B and C. In TableA, we have columnA, used in two of the three views, say A & B. I will see and have to look into view C needlessly to see that while TableA is involved, columnA is not.
Sound simple, right? Exapnd the problem to a serious business database with hundreds of tables, and you could end up looking at a lot of dependencies needlesly when trying to get the ramifications of, for example, a split of an important column.
I guess what you are saying is that, currently as designed, RGDT is unaware of columns as objects? It won't stop me from buying this product, but table-level views for column dependencies just won't cut it. I hope it makes it into some near-term version...
- alphadog / comments
There is a problem with looking at the table-level to understand column dependencies. For example, assume I have TableA, used in three views A, B and C. In TableA, we have columnA, used in two of t...