What are the challenges you face when working across database platforms? Take the survey
Options

Version 3.2.19149.7975 breaks migration scripts

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!
Tagged:

Comments

  • Options
    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
    RedGate Software Developer
  • Options
    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.
    Ivo Miller
    RedGate Software Developer
  • Options
    ducmanducman Posts: 26 Bronze 2
    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.
  • Options
    arturcarvalhoarturcarvalho Posts: 5 New member
    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

  • Options
    ChrisKaczorChrisKaczor Posts: 8 New member
    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.
  • Options
    Ivo_MillerIvo_Miller Posts: 31 Silver 3
    edited May 31, 2019 11:26AM
    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.
    Ivo Miller
    RedGate Software Developer
  • Options
    ChrisKaczorChrisKaczor Posts: 8 New member
    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.
  • Options
    ChrisKaczorChrisKaczor Posts: 8 New member
    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.
Sign In or Register to comment.