New Red Gate SQL Compare beta release with SSDT support

    General discussion

  • Over the last few months, we at Red Gate have been working towards adding SQL Server Database Project compatibility to our main comparison tool, SQL Compare. I’m pleased to announce a beta release of SQL Compare is now available for download from

    This beta allows comparisons and deployments between a database and an SSDT Project (.sqlproj).

    It’s important to stress that this is a beta-quality release of SQL Compare, and as such it is only intended for experimental use.  In particular, we are aware of some limitations regarding database-level extended properties, permissions and CLR assemblies.

    Please give us your feedback on this new SSDT compatibility, so that we can best prioritise bug fixes and provide a robust release in the coming weeks.

    The current beta is free and will remain functioning until 15th May 2013.  We may update the beta as we fix reported issues.

    Many thanks,

    James Allison

    Software Developer – Red Gate

    UPDATE: 15th May, 2013

    The functionality from the expired beta release mentioned above is now part of the main SQL Compare Pro release. Existing users can use 'Check for Updates' from within the tool to update to the latest version. Anybody wishing to evaluate the tool can download a 28 day trial from

    Thursday, January 03, 2013 11:16 AM

All replies

  • Great stuff James. This'll be a big boon for SSDT & Redgate uses.

    ObjectStorageHelper<T> – A WinRT utility for Windows 8 | | @jamiet | About me
    Jamie Thomson

    Thursday, January 03, 2013 11:44 AM
  • Hi Allison,

    How can I setup the SQL Compare to run the comparison between the SQLProject and a database using the beta version? I´m only seeing the same options as the stable version.



    Friday, January 04, 2013 8:33 PM
  • Hi Marcel,

    To set up a database project as one side of the comparison, choose “Source Control” from the radio box.  You need to specify a folder location that contains the .sqlproj file (the project file for SSDT database projects).  This can be either “Direct from source control” or as a checked-out “Scripts folder”.


    James Allison

    Software Developer – Red Gate

    Monday, January 07, 2013 11:28 AM
  • Great, working fine now.

    Any schedule to add this feature to the final product?

    Monday, January 07, 2013 3:25 PM
  • Great, working fine now.

    Any schedule to add this feature to the final product?

    Good to hear it's working for you Marcel!

    The schedule for adding SSDT database project support to the full SQL Compare product depends on how much feedback we get and what problems are reported.  I would be really interested in hearing more about your experience with this feature.  Which object types are in your database project?  Are you using the SSDT database project as the source or target in your database deployment?  Did you encounter any unexpected behaviour?  Feel free to reply here, but if you'd rather communicate privately, please email me at paul dot stephenson at red-gate dot com.


    Paul Stephenson

    Project Manager, Red Gate

    Monday, January 07, 2013 3:54 PM
  • Why would we use this over SSDT to do comparisons?
    Monday, January 07, 2013 10:22 PM
  • Guys, one more question.

    Our project uses a database reference file (dacpac), in order to keep referenced our custom objects to the vendor objects (it´s a mixed solution). It works fine on Visual Studio. However when I run the SQL Compare between the SQL Project and a live Database, the referenced objects are not recognized. According the compare results, they only exists on the target and not in the project.

    Any ideas?


    Marcel Goldhardt

    Dell Inc.

    Wednesday, January 09, 2013 6:02 PM
  • Our project uses a database reference file (dacpac), in order to keep referenced our custom objects to the vendor objects (it´s a mixed solution). It works fine on Visual Studio. However when I run the SQL Compare between the SQL Project and a live Database, the referenced objects are not recognized. According the compare results, they only exists on the target and not in the project.

    Hi Marcel,

    DACPAC reference files are not currently supported by SQL Compare, but it's something we have on our radar.  

    Do your referenced DACPACs change often?  When they do change, would you expect a simple "this database reference file is different, overwrite?" or a fine-grained object-level comparison for everything inside it?

    Thanks for your feedback!

    Paul Stephenson

    Red Gate

    Friday, January 11, 2013 1:12 PM
  • I too am wondering what the "value proposition" is for using Red Gate SQL Compare in place of the SSDT tools.    So far my issues with SSDT compare have included memory limitations, in some cases slower than SQL compare, and a crash issue when closing the comparison window especially when working in 32bit or low memory clients (<=3GB ram).    How does SQL Compare propose to improve upon the SSDT Comparison?
    Monday, January 14, 2013 2:34 PM
  • Hey Nate and Rich,

    Thanks for your questions! We’ve had feedback from some of our existing SQL Compare customers that they would like SQL Server Database Project compatibility added. These users often want to work with the tool they’re familiar with after they move to Database Projects, which is why we’ve released the beta mentioned in the OP.

    We’re really keen for feedback on how people use Red Gate SQL Compare with SSDT support, and would love to hear any thoughts you might have on how it compares (no pun intended!) with Schema Compare in SSDT.

    Tom Lewin

    Red Gate

    Tuesday, January 15, 2013 2:11 PM
  • I'm not going to install beta software, risking downtime or issues with my machine, without there being some documentation of what the benefits are of the product above and beyond what the SSDT tools provide.   But I wish you luck and realize that competition is always good.

    Tuesday, January 15, 2013 2:13 PM
  • I cannot test this.  Says it is a "SQL Compare professional edition feature".   I am licensed for sql toolbelt developer edition.

    Wednesday, January 16, 2013 5:26 PM
  • Another bit of feedback.  I’m not sure why you would make this feature a pro feature, unless you’re going to provide significantly better features.  You’re competing with SSDT compare which is free and as it stands the base SQL Compare is not free.   I’m not sure how you make the sell by tacking on yet even more cost by requiring a pro version purchase.

    For development, we don’t use packaging because developers wind up overwriting the work each are doing on a common sql server.   We do comparisons and sometimes that means selectively sync’ing objects (the ones you know you’ve individually been working on).  So we do tend to rely on comparison quite a bit.   Even when moving changes from dev to test to production sometimes we have to selectively move changes because of simultaneous development work that is going on.  So we don’t always use DACPACs to deploy either.

    SSDT does not, that I am aware of, provide an ability to filter the objects being compared with expressions.   It only allows manual selection of individual objects and often the selections are lost when the list of all objects changes.   We have a “common” database that is replicated between servers.   To keep replication simple, quite a bit of “stuff” is placed in this common database rather than creating multiple databases.  Selectively synchronizing objects between that database and SSDT is a pain because of the number of objects.   It would be nice if a list of object filters could be applied (object and/or schema name prefix/postfix, specific object, for inclusion/exclusion) with a further option setting for inclusion of dependents of matched objects (which SQL Compare does today really)  and save those filters to a comparison definition/project.

    Thursday, January 17, 2013 2:50 PM
  • I cannot test this.  Says it is a "SQL Compare professional edition feature".   I am licensed for sql toolbelt developer edition.

    Thanks for the report.  We've tracked this down to a bug where the Scripts Folder functionality is not available in the beta if you are already licensed for SQL Compare Standard Edition.  Comparing to scripts folders has been a Professional Edition feature of SQL Compare since version 6 (released in 2007), and SSDT projects are a kind of scripts folder.

    We're working on a new beta release that will enable all features for everyone, including those with existing Standard Edition licenses.

    Friday, January 18, 2013 11:53 AM
  • Thanks to all those who have taken time to try our beta of SQL Compare with SSDT project support.

    I'd like to mention that a second release, version, is now available to download from A new expiry date of 15th May, 2013 has been set.

    This release includes improvements to the scripting of constraints, and also addresses the licensing issue identified by Rich Collete, affecting registered users of SQL Compare Std. 

    Many thanks,

    James Allison

    Software Developer – Red Gate

    Monday, February 04, 2013 8:51 AM
  • I'm a little late with my SQL Compare testing. Is there any new Version with a later expiration date?

    Wednesday, May 15, 2013 1:51 PM
  • Hi Andreas,

    The beta functionality is now part of the main SQL Compare Pro release, which you can download from

    To select an SSDT project for comparison, browse to it as you would a scripts folder under source control.

    We're still very interested in feedback - so do let us know how your testing goes!

    Many thanks,

    James Allison

    Software Developer - Red Gate

    Wednesday, May 15, 2013 3:24 PM
  • Hey Rich, I was just reading through your post and you mentioned using a "common" database.  And you had some questions on the value proposition of RedGate compare vs. SSDT. 

    If I understand what you're saying, I think you'll find that SSDT and RedGate are targeted to somewhat different use cases - although looking at the suite of RedGate tools I'm not sure this is totally true.  I do see where some of the RedGate tools will duplicate some of the functionality of SSDT.  So they are in fact competing to some degree.

    I think some of the disconnect that I see is that SSDT seems to be geared more for folks that want to treat their databases more like compiled .NET applications within Visual Studio, and handle the change control as they would with any other common ALM with Visual Studio tools and ALM.  The database compare tools seem to be more functional to getting your projects set up for the first time, making changes on a large scale to an existing database project, or simply as a set of basic tools to sync up two development databases.  They probably don't have to be any more functional than this to achieve the ALM goals - although I won't discourage Microsoft from enhancing them to include additional functionality.

    So in your case, to go with the "common database" route, I think you'd explore setting up a common database project within your source control, then creating branches of that into the database projects that would need that code or be making modifications to that code.  The point is, the source control system would be the thing that is "common", and whatever you have deployed is reflective of what you have in source control.

    Its just a different way of thinking about databases and developing databases - its one that brings database development into the suite of software development for other .NET applications "full-circle", and allows you to handle database ALM as you would handle any other software ALM with a familiar set of tools in Visual Studio.

    Personally, I prefer the SSDT route - it seems to work the best for a highly regulated environment where tight controls over change have to be followed and enforced.  I don't have to have seperate change control processes from my C# application and the Data-tier application that supports it - I can have the same process cover both.  It simplifies documentation for me, and it makes managing that a whole lot easier.

    Monday, May 20, 2013 3:20 PM
  • What would be ideal is that SQLCompare to be able to compare from a dacpac to a DB rather than comparing from the sqlproj.

    Few reasons - 

    1. a DB might be sourced from multiple sqlproj in a single DB solution. When that happens, each sqlproj only tells half the story. It's the Build Output (dacpac) that tells the full story - sqlpackage.exe (from SSDT tools) uses dacpacs to compare to the DB and generate sync scripts.

    2. Like Marcel suggested here, sql projects might have dacpac references (linked servers, etc) in them and those can be resolved easier from the build output

    3. Allowing comparisons with dacpacs will allow developers to keep existing code management processes. We can keep using our builds (TFS integration) to validate code quality, integrate with unit tests, and then when we have a clean (green) build, kick off the deploy process. Most of my DB Builds are set for continuous integration with automated unit tests and deploys to the Dev environment.

    I think adding support for sqlproj and dacpacs is an excellent idea. Keep it up. 

    Friday, November 22, 2013 4:35 PM
  • I know this thread is old but wanted to throw in that we have used Redgates sqlcompare to perform all of our db automation for our software development efforts.   We have our dbs scripted out and checked into github so they are easy to see (very transparent).  Redgate sqlcompare is used to compare the checked in db objects to live dbs in INT environments using the sync switch.   This allows for full CI's of db objects in DEV/INT environments.   For non DEV environments like QA, Staging, Loadtesting and Production,  we use sqlcompare to generate a build to build migration script.  So for example we would generate a db01_to_db02.sql,  db02_to_db03.sql, db03_to_db04.sql, etc.   We have a dbversion table that contains the version info of the db being updated. (eg,, dateupdated, appname, dbname, etc).  We also have a pre-deploy and post-deploy setup for each build that allows for data manipulation.  When we update an environment like QA or Prod,  we determine the current version from the dbversion table, then run each migration up to the target release version.    This is all automatic and does not require a developer or dba to manually apply changes.   The db objects checked in are visible and transparent and easy to understand.

    I have been pressed to look at SSDT and dacpacs but have not found a way to do db automation directly from the checked in database projects db source.  It seems to require a developer to create a dacpac that can be used for deploys.   This dacpac is not transparent and difficult for folks to see what exactly is inside short of having visual studio.  Also using the dacpac approach seems to force updates in QA to be somewhat different than updates to production which means updates of QA are not the same as updates to Production.  I have used sqlpackage to extract a db and publish to create the db or even update the db from a DACPAC only.  This Publish does not work if its just pointed to the source so a dacpac seems to be a requirement.  This means that the source code checked in with SSDT (tables,  sprocs, etc) are just to fulfill the source code requirement but the key is to create a dacpac from the source and then use the dacpac to update the db.  Our redgate approach seems to get this done with more transparency and allows the same scripts that update QA and Staging to be used to update production as well.

    Thanks Lance

    Friday, July 07, 2017 3:22 PM