Re: Redgate Sql Compare 10 Keygen
Martial Salleh
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.
We are also having this same issue where version 13 is crashing on Compare and probably is due to nested parantheses. I followed the advice from Alex B and was able to get the compare to work normally. Just wanted to add in my results if anyone else is having this issue like we are.
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.
The method I used in the end makes use of an SQL Server Agent Job to run a PowerShell script then uses dbmail to email out the results. There are likely to be other ways of achieving the same outcome but this, to me, seemed the most simple.
The first step is to write the PowerShell script that compares the two databases. SQL Compare is a very flexible tool for schema comparison and there are many options available. The script I have included here is pretty much the most basic you can write but it may be all that is required. However, as I said previously, showing exactly what can be done with SQL Compare is not what this article is about. Although you can write directly into your SQL Agent job, in my opinion, it will be easier to create it in PowerShell then copy and paste it across.
This script gives the two servers to be compared (/s1: and /s2:), the databases to be compared (/db1: and /db2:) and creates a report for the output of the comparison (/r:). The /rt switch sets the report type, in this case to Excel. The /f switch at the end tells SQL Compare to overwrite the output file if necessary. If that switch is not included the script will fail if the file already exists.
The next step is to create the SQL Server Agent job to execute the script and email the results. To create the job, there are two options. Firstly you can right click on the SQL Server Agent node then select New then Job as shown in Figure 1 below.
With contributions from MVPs and the SQL Server community, the SQL Monitor team at Red Gate has put together a custom metrics site, SQL Monitor Metrics, to accompany the release of SQL Monitor 3.2. The site hosts T-SQL scripts which can be imported directly to SQL Monitor for custom metric monitoring.
b1e95dc632