Skip to content
← SQL Compare

How can we improve SQL Compare?

SQL Compare

Categories

JUMP TO ANOTHER FORUM

(thinking…)

Compare against Database Projects

It would be great to see SQL Compare support Visual Studio Database Projects (.sqlproj).

Current if you choose Source Control | Scripts, you can point to the project folder, but then SQL Compare gets confused because it loads in extra .sql files (eg. the 'create database'.sql that gets put in the build output 'bin' folder).

Selecting the 'Tables' sub-folder works more reliably (if just comparing tables!), but then pushing changes down to the files results in schema that no longer compiles because the SSDT tools require 'GO' separators between each DDL statement.

5 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
David Gardiner shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Sebastian Crewe commented  ·   ·  Report

    I'm very surprised that there isn't more support for this. SSDT is often the tool used prior to developers discovering the RedGate goodness, so they will likely want/need to continue using that.

    My experience is that everything syncs well from a db instance, eg Development, to an SSDT project via SQL Compare, except for CLR assemblies. I then use SQL Compare from a DEV db instance to the PROD db instance in order to generate the change script.

    As more of us take on the DevOps challenge, we need the full database structure, including assemblies, to be in our SSDT project so as to check for a successful build prior to deploying further to TFS (or other change control) and on down the DevOps tube.