Comments
7 comments
-
More thoughts about the Diff panel:
5. For tables with lots of columns, it would be useful to be able to more easily hide/shrink specific columns. Right now, I have to click+drag both left and right side of a column to "hide" a single column in order to save screen space.
6. It would be nice if there were a way to resize 1 or all columns to fit the width of the data in the columns. E.g. Some columns contain long URLs where the diffs are always at the end of the content, but you can't see the diffs without expanding the columns to display the full content on both sides.
7. It would be very nice if the column headers visually displayed whether there were any differences in that column. That way, I could immediately hide/shrink fully-identical columns if they weren't of interest to me while comparing the diffs.
8. To expand upon #4, it would also be nice to be able to switch the Next/Prev behavior between Right-then-Down (as it is currently) and Down-then-Right. That way, I could easily view all row diffs in a single column at a time, in addition to (or rather than) all column diffs in a single record/row.
9. When switching to the SQL View, the SQL for the selected row/diff should be highligthed and scrolled into view.
10. I would like to see F3 and Shift+F3 as keyboard mnemonics for the Up and Down buttons next to the Find box in the Diff panel.
More feedback later... -
11. It would be nice if the order/sequence of the columns could be changed in the diff panel. This enhancement is separate from but complementary to #5 and #7.
12. It would be nice if the order/sequence of the records displayed in the diff panel could be changed. E.g. If I could sort the records by the values within a particular column (either the Before or After values). This enhancement is separate from but complementary to #5, #7, and #11.
13. It would be nice if the records displayed in the diff panel could be easily filtered (without adding a where clause in the table mappings). E.g. The "All rows", "only in", "both but different", etc. tabs at the top are a good start, but it would be nice to have additional filtering and navigation options to help the user focus on and work with a particular subset of the records. E.g. If I have 10K records with diffs, I might want to tell the app: "Show only records where (the values in column A are different) AND (the Before value in column B is > [yesterday]) AND (the After value in column C is <= the Before value in column D)". That would enable me to view a much smaller set of records in order to decide which (if any) of them I want to sync. This kind of scenario occurs frequently in my dev work, because different environment usually have many records that differ necessarily, and I am often looking to sync only a specific subset of the differing records.
14. The Pivot view is neat and I could see that it would be very nice in some situations, but it would be usable much more frequently and effectively if enhancements #5, #7, #11-#13 were to be implemented.
15. I have found on many occasions that it is necessary to only sync diffs in selected columns, but to ignore diffs in other columns. This is related to the issue of viewing/ignoring certain cols/rows in the diff panel, but is instead related to the actual sync script. E.g. If I am comparing and syncing a Training environment with a PROD environment, I would want to be able to sync the values in some columns (such as a Name column and/or a Status column), but I would not want to sync/change any values in certain other columns (such as credit card numbers, passwords, environment-specific paths/urls, etc.) because doing so would either break the synced environment or cause a security, privacy, or other similar problem. This use case does not appear to be adequately addressed in the Alpha version.
15b. FYI: I would very much like to see similar "fine-grained sync" enchancements in SQL Compare, because sometimes multiple differences in constraints, indexes, etc. exist on a single table, and I would love to be able to include/exclude individual differences when syncing, rather than being forced to include/exclude all of the changes that exist for the entire table/view/proc. Another good example would be when you want to partially sync differences between roles/permissions on 2 DBs. You may want to copy one of a role's members from DB 1 to DB 2, but without removing any members that already belong to that role only on the synced DB.
16. The "Right Click + Show Viewer" feature doesn't appear to do anything at all. -
Hi Justin,
Thanks for all the ideas - here goes!
1. Once you've run the comparison, on the main window, you'll notice a red arrow pointing from left to right at the top - double-click this, and it'll change the direction of the comparison. I think this should give you the functionality you need?
2. Interesting, I don't think that's something we've considered before, but it's a nice idea, thinking about it.
3. Cool :-). Please keep trying it on any backups you have sitting around - now's the chance for you to tell us what *doesn't* work!
4. I think there's quite a few missing keyboard shortcuts in the alpha - this is obviously something we'll be fixing before release.
5. You can choose which columns are included in the comparison in the project configuration wizard, though this will also stop those columns being checked for differences, which might not quite be what you're after.
6. A nice idea, though of course there's the slightly tricky part of working out how wide a column should be when you've got a million rows to search through. I'll certainly note it down as a suggestion.
7. Interestingly this was something we looked into earlier on in development, but we didn't think it really worked in a sensible way. Maybe it's something we should think about again, as a few people have been after it.
11. Yes, good point. One workaround for now would be to define a view on the table you wanted to re-order the columns for, having the columns in the order you want. This isn't a great solution, I know...
12. You should be able to click on the column headers to sort the rows by any column you want - I think that's what you're after?
13. When you're setting up your project, have a look at the filter / "where clause editor" in the project configuration wizard. This lets you set an arbitrary WHERE clause for each table, letting you do exactly that. The slight caveat is that it won't work for backups.
15. See #5 - you can choose which columns to include in the comparison on the "Tables & Views" tab of the project configuration wizard.
16. Well spotted - this is a bug. You can invoke the viewer by double clicking on the field as well, which does work.
The points I haven't replied to are all good suggestions, and have been noted; I just didn't have anything particular to say in response to them!
Cheers,
Robert -
Robert,
Some comments about your responses:
1. I already know about switching the sync dir. That isn't sufficient because if you are syncing changes from DBsource to DBtarget, then it is often much easier to read and understand the diffs when the "old" DB (i.e. DBtarget) is on a specific side of the screen (regardless of the sync direction).
5. IMO, that isn't a feasible workaround, both because of the amount of effort involved and also because it might still be necessary to know if there are diffs in the column. E.g. I might want to see all records whose "last modified" value has changed, but I often wouldn't care (much) what the new value was, I'd want to view other columns such as Name or Modified By instead.
6. You're already displaying the data, so just loop through it and do the calculation. I didn't ask for the auto-resize to be fast on millions of rows of diffs. Usually I'm working on sets withs < 1000 diffs per table, and I want the resize to take only the displayed rows into account, so perf shouldn't be an issue most of the time.
7. You already make a distinction between rows that have changed vs. ones that are identical. This idea is really the same thing when you're viewing the Pivot View, but it would still be useful even in the normal view.
11. That isn't a feasible workaround, for the same reasons as in #5 above, plus the fact that I would usually want to reorder the cols after running the comparison, and often would want to reorder them multiple times during the same comparison in order to easily view the diffs from different perspectives.
12. You're right, I missed that. Good job!
13. If you look at my original suggestion, I specifically mentioned not wanting to use the where clause editor. I'm talking about dynamic filtering of the comparison results, not pre-comparison filtering of the data being compared. The reasons for being able to do this are the same as described above in #11.
15. Your workaround suggested in #5 for #15, could partially address the issue in some cases, but IMO it isn't very easy/productive. Also, it still requires that I know ahead of time which cols have changed. I'm talking mostly about the situation where I want to see all changes, but I want to selectively approve/veto each one, which would often involve approving a subset of the changes from each modified column/record, but not the same columns for each record. In that scenario, your suggested workaround is completely unfeasible.
A side note:
Please understand that all of these suggestions are what would work well and enhance productivity for me and my colleagues. I'm pretty good at coming up with workarounds like most of the ones you suggested on my own, but oftentimes such workarounds involve as much or more effort as alternative workarounds done without your tools. E.g. For #15 I would probably just generate the full change script, then load it up into an editor and manually modify it. This workaround is still is nowhere near ideal IMO (ideal would be the enhancements I suggested), but it's often better, faster, and less prone to errors than running a bunch of different comparisons with different projects/configurations and generating a bunch of separate migration scripts all using your tool.
It is my experience that whenever a rapid development/developer productivity-type app requires me to put significant time and/or effort into a workaround in order to use the tool for something, that is almost always a signal that it would be better to not use the tool to accomplish that task (either at all, or in any way significantly beyond its design).
I do appreciate the effort you put into the suggested workarounds, but please understand that my suggestions are meant to significantly enhance the productivity benefits of your tool for me (and other devs like me, of course). As a former lead architect and developer of a rapid application development app, I understand that sometimes it makes sense to not implement certain features at certain times in dev tools, but please don't make the mistake of thinking that a complicated, difficult, or partial workaround is an acceptable alternative to the suggested enhancements.
To put all of this into perspective, I already think you have a great product that really boosts my productivity in many situations. However, if some or all of my suggested workarounds were implemented, I think you would have an extraordinarily great product that really boosts my productivity even more in an even larger number of situations.
Keep up the great work on all of the Red Gate tools! -
Hi Justin,
Thanks for the detailed reply - it's great to get such good feedback from people.
I think the flexibility of the rows grid is certainly something we need to look into - I can't promise what we can get done in time for release: as I'm sure you realise, if we added every feature that was requested, we'd never actually get the product finished, but we'll certainly do our best.
Also, please don't think that if we don't get something in for this release, it gets forgotten about - even those that don't get put in are kept as ideas for future releases.
I understand where you're coming from with wanting to be able to change more things after doing the comparison, and I'll see what we can do here. I definitely can't see the ability to dynamically filter values going in for v6 - there just isn't enough time - but some of the smaller (yet probably just as important) features might well do.
I know what you mean about a bad workaround sometimes being worse than doing it from scratch, and our goal is to make something powerful enough that you should need as few of these as possible to do what you want. However, at the same time, we want to keep it "ingeniously simple" to use, so you don't need to spend months learning how it works before you can compare two tables :-).
Thanks again for the feedback - any more thoughts, please feel free to post them...
Cheers,
Robert -
Excellent. I think you guys and I are of a similar mind, then. I didn't expect all (or even most) of my sugestions to make it into v6 at this point, I just wanted to be sure that they were taken into serious consideration for upcoming enhancement planning.
A couple of other suggestions:
17. It would be nice if there more options in both Compare tools for specifying how the migrations scripts are generated. E.g. Options could include:
17a. to embed code comments to make the script self documenting
17b. include header/summary comments at the beginning of the script that summarize the script's contents (i.e. similar to the stuff that is displayed by the Sync Wizard before the final step).
17c. to embed user-friendly output statements to make it easier to verify and/or debug runtime execution of the script
17d. to generate the script as "grouped" commands, by surrounding similar statements in BEGIN/END blocks
17e. to generate TRY/CATCH blocks around each "group" of commands. These would have default behavior, but would also make it easier to customize a generated script.
18. During DB development, when new tables, constraints, and/or columns are added it is sometimes impossible to sync the schema without syncing or changing the data, which means that both SQL Compare and SQL Data Compare need to be used, and in a specific sequence. Therefore, it would be nice to have a way to further automate some of these issues. E.g.:
18a. When creating a new table, allow optional insertion of all existing data into the table at the same time.
18b. Allow the user to specify a "default value for existing records" for new columns that only applies to the existing records, but doesn't affect the column's actual default value.
18c. Possibly allow both Compare products to "sync to named/existing script", which would allow the user to "build" a single large script by sequentially appending the output of successive sync operations to the same script. -
Wow there's some good suggestions there. I think some of the issues we have with adding comments to especially SQL Data Compare scripts is that they can be so large that the comments can seriously increase the size of the generated script.
As to getting more options and integrating the two SQL generation engines that's a long term goal although we've no concrete plans for when we would undertake such a large scale re-engineering.
Generally I agree with most of your other suggestions and we'll put them in the system so that they can be considered for future releases.
Thanks again for all your feedback on the Alpha, it continues to be very helpful.
Add comment
Please sign in to leave a comment.
2. Neither Data Compare 5 nor 6 Alpha "remember" server names. I find that very frustrating, since I almost always compare between 2 of my development servers and/or several other servers in a different domain, and I always have to type the full server names in for the ones in the other domain.
3. The compare Live DB to SQL Server Backup is GREAT! I used to routinely restore my backup files to a temporary DB to do this, and this will save tons of time.
4. I also love the "next" and "prev" buttons in the Diff panel. However, I'd like to see "next record" and "prev record" buttons added also, to skip to the next line/record. I'd also like to see some 1-key shortcuts for the Next buttons (e.g. F2, F3, F7, or F8 to most closely match VS.NET, VSS, or other similar "go to next" type mnemonics.). Of course, configurable keyboard shortcuts would be even better. FYI: I don't really care for the Alt+Down/Up mnemonics used by SQL Compare 6's Next/Prev.
I'll post some more later after I play with some more features.
Thanks for yet another great boost to developer productivity,
Justin