Settings and activity
2 results found
-
5 votes
An error occurred while saving the comment 
Sebastian Crewe
supported this idea
·
-
16 votes
An error occurred while saving the comment Sebastian Crewe
commented
Sorry - one more thought: it would be important to preserve the variable syntax when deploying changes from the database to the SSDT project. If the other way around, it would be equally important not to make a variable out of the distinct reference in the database.
I'm trying just now to use SQL Compare to update my SSDT project. For a changed script where variables are in play, I'll have to manually change the true updates (some VARCHAR arguments) so as not to have my variables overwritten.
Sebastian Crewe
supported this idea
·
An error occurred while saving the comment Sebastian Crewe
commented
Yes, I think something like this is required for working well with SSDT projects. Showing up a difference because a project object uses a variable while the database equivalent does not is essentially 'noise' - a false positive.
However, the ideal could be for SQL Compare to recognise the variable syntax and mark the two objects as equivalent as long as what follows matches on both sides. This way, there would be no need to select another option. I guess the feasibility of this depends on whether SQL Compare recognises that it is dealing with an SSDT project (versus a collection of scripts) and can apply different comparison logic accordingly.
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.