Comments
Sort by recent activity
I found a bug a few weeks back that affected comparing white space. It was in the VS extension but maybe it is also in certain versions of the cmdlets. I was able to see this by using SQL compare to compare my VS project against the database. Make sure you have the setting in SQL compare to include white space. Might not be the issue but something to check. / comments
I found a bug a few weeks back that affected comparing white space. It was in the VS extension but maybe it is also in certain versions of the cmdlets. I was able to see this by using SQL compare t...
This looks to be the same issue but on octopus instead of jenkins. https://forum.red-gate.com/discussion/84067/octopus-step-templates-throws-always-warning-about-f-anonymoustype0-1 / comments
This looks to be the same issue but on octopus instead of jenkins. https://forum.red-gate.com/discussion/84067/octopus-step-templates-throws-always-warning-about-f-anonymoustype0-1
This sounds great and I would be happy to help contribute code. / comments
This sounds great and I would be happy to help contribute code.
I was just working on a script to generate the NuGet package version and I ran across this page today. https://docs.microsoft.com/en-us/nuget/reference/package-versioning I assume your issue is that the -Suffix must start with a alpha character. The one that worked started with -e the ones that failed start with -0. / comments
I was just working on a script to generate the NuGet package version and I ran across this page today. https://docs.microsoft.com/en-us/nuget/reference/package-versioningI assume your issue is that...
@PeterDaniels You posted this as a discussion not a question. I have done this before as well. / comments
@PeterDaniels You posted this as a discussion not a question. I have done this before as well.
PackageVersion is for the version of the Nuget package. In my process I publish the package to a Nuget feed and other tools will know when to pick it up based on that version. I don't think PackageVersion applies to you since you are manually handing the script to your Ops. Redgate should probably address the other questions. On a side note it would be nice to see Redgate take a little time in making some guides, documentation, strategy , videos, etc for people using SCA like this. I think this is and will be a common approach to introduce the tool in baby steps while building up confidence or waiting for resources to free up to implement. A lot of the documentation and marketing is geared towards CI/CD and that's a great goal but in the real world a lot of us need to take a phased , agile approach. / comments
PackageVersion is for the version of the Nuget package. In my process I publish the package to a Nuget feed and other tools will know when to pick it up based on that version. I don't think Package...
It's a valid concern. Maybe someone from Redgate could chime in with ideas on how to prevent a disaster if the table was dropped or altered. After your fist deployment you could add a check to see if the table exists and has some rows before your deployment can happen. Depending on your situation though there may be valid cases where that table does not exist, like deploying to a new environment. / comments
It's a valid concern. Maybe someone from Redgate could chime in with ideas on how to prevent a disaster if the table was dropped or altered. After your fist deployment you could add a check to see ...
I refresh our lower environments all of the time from PROD and you want the _MigrationLog table to be refreshed as well so it also represents what has already been deployed to prod. / comments
I refresh our lower environments all of the time from PROD and you want the _MigrationLog table to be refreshed as well so it also represents what has already been deployed to prod.
"Mark it deployed" is for when the change is already made in DEV. You don't want it deployed again in DEV. It will still be deployed in other databases where its not set as deployed in the _MigrationLog table / comments
"Mark it deployed" is for when the change is already made in DEV. You don't want it deployed again in DEV. It will still be deployed in other databases where its not set as deployed in the _Migrat...
First part of your question Correct: 0 for baseline script and 1 for the change scripts 2nd part, DON'T DROP THAT TABLE, bad things will happen!!!! In all seriousness yes baseline should not get run again but your other migration scripts will run. You could code each migration script so that it could be re-run and not cause issues. For example have an if exists statement that checks if your change was already made. Another option might be to re-baseline. https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/advanced-project-manipulation/re-baselining But the best option is just don't drop that table [image] / comments
First part of your question Correct: 0 for baseline script and 1 for the change scripts2nd part, DON'T DROP THAT TABLE, bad things will happen!!!! In all seriousness yes baseline should not get ru...