Download Sql Compare Redgate
Shanae Maerz
I first started using Redgate SQL Compare when I was at Glass's in 2003/04 and I'm still using it 4 years later. Over those years the product has evolved and new products have been released from Redgate. I have only ever used it for SQL Server (7, 2000 and 2005) and so can't comment on it's appropriateness or reliableness targeting other database products.At the time that I first found SQL Compare, there weren't that many tools available that did a reliable job of comparing objects and producing scripts of the differences. I know that one of my colleagues at Madgex is a fan of SQL Delta. One day we sat down to compare the tools and discovered that there really wasn't much to choose between them.I have always used SQL Compare more as a tool to check my scripted updates, rather than to produce those scripts. After a bad experience at a previous company when a member of my team managed to empty an articles table rather than update it when manipulating the database via Enterprise Manager I've habitually manually created defensive SQL change scripts with appropriate transactions and error handling.SQL Compare is simple to use, works quickly and produces a detailed list of differences between database objects. The differences that are detected are configurable, so you can choose to ignore or report upon white space or comment differences.When you first open the screen you are presented with a screen offering options of what you want to compare.Once you have registered a couple of databases to compare, it is a short wait until the differences are displayed.The display of differences are divided into:
For each object that is different you can choose to view the details of that object which will display a SQL based description of the object with the differences identified by a highlight line - sometimes it might be the whole object, a part of an object (i.e.a column definition) and sometimes it will be a constraint, or a grant statement that is missing.From the summary screen you can select the changes that you're interested in and get SQL Compare to automatically synchonise your target database to match the source, or vice versa. You can also get it to generate some SQL to do the generation to allow you to put your SQL upgrade scripts into a build process, or under source control. In the majority of cases I will use this tool to check my upgrade scripts, rather than to produce them and if I spot any difference I tend to write my own, defensive, SQL to make the upgrade scripts.In the 4 or so years I've been using SQL Compare I've found it to be a stable, evolving product which I have come to rely upon completely to check upgrade processes. I made the most use of this tool at Glass's where I was working on a product which was client/server application where it couldn't be relied upon that the customer was always running the latest version. Consequently, our preparation for release process involved installing the earliest supported version of the system, and upgrading it to the release candidate on one machine and installing a clean, new build of the release candidate from scratch and comparing the two and producing upgrade SQL scripts for any identified differences before starting the process again. We also included a call to the command line version into the automated MSBuild process producing an HTML report of the differences which could be used to fail the build if anything other than 0 differences was reported.
I know weird to with a MS SQL Server, but many people who have been on the platform for a while now have developers with Macs, and automation systems on linux. DLM Automation is pricing some of us out of the Redgate ecosystem. With SQL server now running on Linux seems a reasonable path. I sure hope our beloved sql compare is not going away :(
It's also worth noting that this would be a great service to development teams that choose/need to develop on MacOS/Linux and consequently have to live with the licensing costs of both the virtualization-software and their Windows-VM in order to keep using your tools with a product that is now arguably cross-platform.
Another vote for CLI tools, no need for any GUI ports! Just make sure we're able to link/unlink static data, as this is currently only possible through the SSMS-plugin, and SSMS is not yet cross-platform either.
It would for me! The tea leaves that I'm reading show a commitment by MS for running SQL on Linux. In my opinion, there should be options for third-party tooling to also run there. CLI fits very much within the Linux ethos, so I don't even think that'd be seen as a bad first step.
All of your personal information, including email address, name, and IP address will be deleted from this site. Any feedback you have provided that others have supported will be attributed to "Anonymous". All of your ideas without support will be deleted.
I currently use the Visual Studio Professional Edition which has the database project as a project template, but some of its features are not available, for example Schema Compare tool. The schema comparison and database update scripts generation are only available in Visual Studio 2010 Premium/Ultimate versions.
But are the schema comparison and update scripts generation features in the Visual Studio as rich as those in Redgate SQL Compare tool? (I didn't use it either) I didn't manage to find the feature comparison list. Could anybody, who used both of them, help to make it clear?
I tried to use the VS tool yesterday with my production SQL 2000 instance, comparing to my dev 2008 instance, and it refused to work with anything prior to SQL 2005. Red Gate definitely does not have such a restriction. It even works reasonably well (not 100%) with another database we have that runs in 6.5 Compatibility Mode.
It's been a while since I used Red Gate, but the VS2010 has it matched from what I remember, with options to include or exclude by object types, and generate scripts to match the two schemas; the VS tools takes a while to run, I remember the Redgate to be pretty quick.
I'm personally using only Visual Studio with Database Edition GDR, because it's better for my needs. What I like about it mostly is the fact that I'm able to compare db projects with the actual databases. The tool can also compare databases, not only projects.It's true that the schema comparison tool itself is not very fast and has some quirks, but I managed to work with it very well and didn't need any other tool for years now.
I am sure that a separate tool is faster (I used in the past) and maybe has more options, but you can leave with what ever choice you make without any problem. I didn't use it much for data comparison (feature that's included in Visual Studio and not in RedGate's tool, which requires a different tool - Data compare), so I can't say how fast it is.
I couldn't find the feature comparison list between Visual Studio and Redgate, but I ran into a post that compares the performance of 2 SQL schema comparison tools - ApexSQL Diff and Redgate SQL Compare: -diff-2015-r3-vs-redgate-sql-compare-11-2-1-comparative-performance-test-of-live-databases-and-backups/
For what redgate does that VS dosn't its really not worth paying all that extra money. Redgate tools are seriously over priced. Redgate is a little nicer to use but you would have to use it an awful lot to justify paying that much on an extra tool.
I have a situation in my current position where we have an engine that produces output to a data table that affects the manufacturing floor. We have a need to do regression testing whenever a change is made to this engine. In this case we will restore a backup of the production database in test and then run the same job that was run in production and compare the results. In most cases the data should match exactly. In a few cases we expect different data because of the engine change.
When I use Redgate SQL Data Compare API, I will set the server to be the same, the database will be the same, the table will be the same. I will change the key so it is no longer the primary key of the table to a Serial Number column that stays the same across runs of the job in the engine.
Declare the database and session variables. Just like SQL Data Compare, you have to setup and register your two database connections. In this case since they point to the same server and database it is pretty straight forward.
Set the WHERE clause so we know which sets of data in the table to compare against. In my case, each job run is given a unique HeaderID so I can use that when comparing the two sets of data in the same table.
In my actual use, I call this compare multiple times and just pass in different HeaderIDs. The registering of the databases takes the longest amount of time, so I do that first and then hold on to those objects and call the data compare just passing the database and session objects in. For me this process decreased the time it takes to do regression testing. It also does a better job since we know the old and new data matches exactly.
By default, SQL Prompt shows code auto-completion suggestions automatically, and continuously. 90% of the time this is exactly what you want, but there are other times where you just need a bit of space - Phil Factor shows how.
e59dfda104