Version 3.2.19149.7975 breaks migration scripts

ChrisKaczor

This morning we noticed that all of our SQL deploys (against Azure SQL) were failing - based on the logs it looked like the deploy was trying to re-run old migration steps which obviously aren't valid to run again.

When comparing the working deploys to the broken deploys we found that the working ones were built with SQL Change Automation version 3.2.19141.7818 and all the failing ones were built with the 3.2.19149.7975 version.

On further digging into the artifacts we found that the SQL script built with 3.2.19141.7818 would wrap each statement in an EXECUTE and that version 3.2.19149.7975 no longer does this.  It looks like this causes SQL at least try to parse the migration step which fails because the schema is different from where it was before.

This is a major breaking change/regression from the previous version - I can't imagine any real-world migration script that can still parse old migration steps against the new schema.  In our case there is an old view in the migration script that references a table that has since been deleted - this clearly won't parse or run.

Is there a way to get the old behavior back until this bug gets fixed?

Thanks!

Ivo_Miller

Hi. Many apologies for your issue.
The old behaviour can be restored by setting environment variable "RG_UseExecuteStatementsInPackageScript" to "true".
We will look to release an update fixing the issue soon.

Ivo_Miller

Also, if you are using the ReadyRoll.MsBuild nuget package via the ReadyRoll AzureDevOps plugin you can make the plugin target the last working version (3.2.19141.7818) by selecting "specific" under ReadyRoll version and specifying that version number.

ducman

We ran into this issue the entire day yesterday. We also did our own digging and found the exact same thing. We fixed it by specifying the previous (working) version number (as said above) and everything is back to the way it was.

arturcarvalho

This morning we found the same problem... We fixed it by specifying the previous version number...
I agree that is a major breaking change/regression from the previous version

ChrisKaczor

The "RG_UseExecuteStatementsInPackageScript" workaround seems to be doing the trick for now.  The version of the plugin we're using with TFS doesn't let us specify which version to use so as a second step we're going to look into updating the plugin so we can do that.

The much bigger issue is that this is the second breaking change we've run into recently (see https://forum.red-gate.com/discussion/comment/156277#Comment_156277) - specifically using an older version is okay but it worries us that updates are coming out broken.

Ivo_Miller

We have pushed a new version of the ReadyRoll.MsBuild package, 3.2.19150.8056, where the behaviour change has been reverted. Apologies again for the inconvenience caused.

ChrisKaczor

The "RG_UseExecuteStatementsInPackageScript" workaround seems to be doing the trick for now.  The version of the plugin we're using with TFS doesn't let us specify which version to use so as a second step we're going to look into updating the plugin so we can do that.

The much bigger issue is that this is the second breaking change we've run into recently (see https://forum.red-gate.com/discussion/comment/156277#Comment_156277) - specifically using an older version is okay but it worries us that new versions are being released with these major issues.

ChrisKaczor

The "RG_UseExecuteStatementsInPackageScript" workaround seems to be doing the trick for now.  The version of the plugin we're using with TFS doesn't let us specify which version to use so as a second step we're going to look into updating the plugin so we can do that.

The much bigger issue is that this is the second breaking change we've run into recently (see https://forum.red-gate.com/discussion/comment/156277#Comment_156277) - specifically using an older version is okay but it worries us that new versions are being released with these major issues.