Options

Disable verify in SQL Change Automation

Simon501Simon501 Posts: 2 New member
in SQL Change Automation
Hi. I have a database that I am trying to use SQL Change Automation with. The database is quite old and has a lot of objects, such as views and SPs, that reference objects that no longer exist. There is also quite a lot of 3-part naming in the database too. When I push the project to source control, the verification of the database fails. Is there any way I can turn off verification of the database when pushing to source control (without using filters)?
Tagged:
· Share on Twitter

Answers

  • Options
    TheMaskedDataTheMaskedData Posts: 50 Bronze 3
    Hey @Simon501 just to clarify - do you mean the very first time you try to source control the DB? So you've connected to Dev as your development source and Test to take your baseline - and now the verify is failing because it's trying to build the Shadow Database from the baselines script?
    · Share on Twitter
  • Options
    Simon501Simon501 Posts: 2 New member
    Sorry, I wasn't very clear above.

    Specifically I'm trying to create a database Artifact in a Github workflow using the New-DatabaseBuildArtifact PowerShell cmdlet. This relies on a project having a clean build from the Invoke-DatabaseBuild cmdlet. The problem I have is that I can't get a clean build due to numerous errors in the database (which I can't fix). I still want to package the database and send it to downstream environments. Is there any way I can get a package of a database in a Github workflow without having a clean build?
    · Share on Twitter
  • Options
    TheMaskedDataTheMaskedData Posts: 50 Bronze 3
    Thanks Simon - no problem, thanks for clarifying! 

    It's a tough problem, in the past I've used SQL Clone to get round this because you can integrate SCA with it and it does builds on top of the cloned DB, which gets around the "deploying the full DB in the build problem" - if you have access to that, it could potentially help? Although I think if you're using SQL Source Control as the method for source controlling this wouldn't help.

    The other option is I believe asking the question "do we even need to do a full build?" - whilst there is obviously value to a full clean build, invalid objects and unfixable problems mean that it's really just a blocker to the rest of the process.

    Is there any reason why, instead of a build, you couldn't just zip up the files as part of the pipeline and pass the zip file along instead of the build artifact?
    Once pushed down the pipeline for release you can then just carry on as normal and pass it to the New-DatabaseReleaseArtifact cmdlet (Docs: https://documentation.red-gate.com/sca/reference/powershell-cmdlets/new-databasereleaseartifact) - I'm running off of my older knowledge here as it's been a while since I used SCA specifically but I think (and it looks like) it might accept a zip folder of the files from your GitHub repo instead of the NuGet specifically...

    I'm sure one of the tech folks from Redgate's side, or maybe their support team would be able to give an even better answer than me, but it might be something to explore initially if it helps you get started :smile:
    · Share on Twitter
Sign In or Register to comment.