1 August 2017

1 Comment

1 August 2017

1 Comment

A whole new way to see differences in SQL Compare

In the latest release of SQL Compare, we’ve added a brand new way to examine the differences between two objects in your database.

Until now, SQL Compare has relied on the SQL difference viewer to convey the differences between an object in the source database and its counterpart in the target database:

Summary view 1

Don’t worry, this isn’t going anywhere, but many of you have told us that it can sometimes be difficult to see what the differences are with the SQL viewer alone. For example;

  • Syntactic differences, like the addition or removal of trailing commas, are highlighted but are semantically irrelevant
  • Columns in different orders in the source and target cause entire rows to be highlighted as different, when in fact there is no change at all
  • Features that are often ignored, like constraint names, are still highlighted as different despite having no effect on any subsequent deployment
  • Constraints that are inlined on one side but not the other result in both being highlighted as different, but in fact they are semantically identical

To make it easier to see the differences, SQL Compare 12.4 adds an alternative way of viewing the differences between objects in a database.

The brand new Summary view is a tab that sits alongside SQL view and provides a more concise breakdown of the differences between two objects. We’ve achieved this by getting rid of the SQL and showing only the semantic differences between objects in a much more structured way:

Summary view 2

You can now clearly see the addition of a column, a modification to another, and a change to a primary key constraint in the example above.

We’ve also added some simple color coding to help you quickly identify what’s missing (grey), what’s identical (yellow), and what is being changed from source (green) to target (red).

This new way of checking the differences will eliminate a lot of the confusion that can be caused by noisy diffs in the SQL difference viewer.

But that’s not all…

Column ordering in SQL view

You also told us that it can be difficult to see column differences in SQL view because the order of columns is not always the same between the source and target. In SQL Compare 12.4, we’ve improved the SQL difference viewer so that it always displays the columns in an order that makes it clear exactly what the differences are:

Summary view 3

Now that the columns are displayed in the same order on the left and right sides, it’s much more obvious that the only changes here are those relating to the DEFAULT and NOT NULL constraints.

Color highlighting in SQL view

In addition to improving how columns are ordered in the SQL difference viewer, we’ve also made changes to the colors used to show differences between the left and right sides, to match the new features in the Summary view.

Previously, the differences on both sides were shown in yellow. Now the differences in the source database are shown in green, and differences in the target database are shown in red.

Summary view 4

By moving to this color scheme, commonly used in other diff viewer tools, we’ve increased the visual contrast, making it easier to see at a glance where the differences are between the source and target.

The change to the color scheme also makes it clearer that the changes to the source database, in green, will be added or applied to the target, and those changes to the target database, in red, will be removed or overwritten.

We hope you like the new features in SQL Compare 12.4. If you’re an existing customer, go to the update banner bar in the product to upgrade to the latest version, or click Help > Check for updates.

If you haven’t used SQL Compare before, download your 14-day free trial now to check out all of the other features available.

Tools in this post

SQL Compare

Compare SQL Server schemas and deploy differences fast.

Find out more

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Hub

Misuse of the scalar user-defined function as a constant (PE017)

Do not use a scalar user-defined function (UDF) in a JOIN condition, WHERE search condition, or in a SELECT list, unless the function is schema-bound. Scalar UDFs are often used without a parameter to...

Also in Product learning

Customizing the SQL Prompt built-in snippets: a better 'ata' snippet

Snippets are a great feature of SQL Prompt. They save coding time, and introduce standards and consistency to the way you build code modules. They have multiple replacement points (placeholders) for p...

Also in SQL Compare

How to reformat a database in one operation

Inherited a database from another team? Changed your team policy on the way that you format SQL? What's to stop you formatting the code of an entire database nicely, when you're developing it? It can ...

Also about SQL Compare

How to Customize Schema Comparisons using Auto Map in SQL Compare

It's a tedious task to have to compare two versions of a SQL script, side by side, for example to find differences between the version of the script on Production, and the one on the Test system. As a...

  • Brian

    Hi Jamie,

    I’m a little confused. I’ve been using SQL Compare for many versions, and two of your four points seem wrong to me. I’m talking about these:

    * Columns in different orders in the source and target cause entire rows to be highlighted as different, when in fact there is no change at all
    * Features that are often ignored, like constraint names, are still highlighted as different despite having no effect on any subsequent deployment

    I’m pretty sure by default that the comparison to ignore column order is on by default. But even if it isn’t, it’s trivial to turn on that option. Same goes with system-generated constraint names or just constraint names in general.

    The new feature looks cool, I just think your justification used a couple of points that weren’t really good justification.

    -Brian Eriksen