User profile for Justin_W

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. / comments

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 in...

0 votes

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! [image] 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! / comments

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...

0 votes

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. / comments

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/seq...

0 votes

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... / 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 righ...

0 votes

How can we help you today?

Justin_W

Comments