Comments
Sort by recent activity
SQL Compare does not look at the data in your databases, only the schema. If you drop a column the data is gone.
If you would like to be able to restore it you need to make sure you have backed up the data somehow first.
How much data are we talking about?
For small (<1000 rows-ish) lookup/reference/static data, tables where devs manage the data (eg product codes, person type), you can use the static data feature of SQL Source Control to version the data so you can roll it back later but this is not suitable for large tables or transactional data.
If you want to be alerted whenever SQL Compare will drop a table you should be able to set the max warning level to your taste to fail/abort the build. I believe column drops are high level warnings. / comments
SQL Compare does not look at the data in your databases, only the schema. If you drop a column the data is gone.
If you would like to be able to restore it you need to make sure you have backed up ...
If by VSO you mean VSTS, yes it does.
You can link either to a TFS style repo or a Git style repo.
Note that if using Git with VSTS the commit and get latest options will work fine but Push/Pull won't. Some odd permissions issue.
You could avoid this by using the "working folder" option but this does not fix the problem it just hides it and in the process you lose other functionality. Better to just link as normal and use and external git client or the git command line to do your push/pull. / comments
If by VSO you mean VSTS, yes it does.
You can link either to a TFS style repo or a Git style repo.
Note that if using Git with VSTS the commit and get latest options will work fine but Push/Pull w...
That is fair - and it's a question for someone in the dev team. :-) / comments
That is fair - and it's a question for someone in the dev team. :-)
You could try creating a single PowerShell script (with parameters) that you could add to source control once to handle your deployments. Then, instead of using the plugin you can simply call that same PowerShell script for each build.
This way your configuration for your deployments is in just one place and it is under source control. / comments
You could try creating a single PowerShell script (with parameters) that you could add to source control once to handle your deployments. Then, instead of using the plugin you can simply call that ...
How have you set up the deployment to work in TeamCity? To create a backup (more reliable, involves downtime):
If using SQL Compare command line: https://documentation.red-gate.com/display/SC12/Switches+used+in+the+command+line#Switchesusedinthecommandline-/MakeBackup
If using DLM Automation, ReadyRoll or the TeamCity plugin (which uses DLM Automation under the hood) you will need to add an additional pre-deploy step to take a backup. To generate a roll-back script in advance (but if upgrade fails, rollback script is unlikely to work either):
Try adding a build step before your deployment to call DLM Automation with PowerShell or use SQL Compare command line to generate a rollback script and save it as an artifact before executing the deployment. / comments
How have you set up the deployment to work in TeamCity?To create a backup (more reliable, involves downtime):
If using SQL Compare command line: https://documentation.red-gate.com/display/SC12/Swit...