Activity overview
Latest activity by Garth_Martin
Thanks Christian, will take that under advisement. / comments
Thanks Christian, will take that under advisement.
Thanks for your reply, but it seems to contradict the page I linked. It clearly says "with the exception of" for SQL MI. Any other ideas? [image] / comments
Thanks for your reply, but it seems to contradict the page I linked. It clearly says "with the exception of" for SQL MI. Any other ideas?
SQL Managed Instance as deployment target
We are considering moving our production environment to SQL Managed Instance, but will be leaving all other environments as-is (i.e. VM based SQL instances SQL 2022). Will SCA 4 work properly in t...
Thanks, that would likely work as well, but I fixed it by appending the buildId to the nuget package name. / comments
Thanks, that would likely work as well, but I fixed it by appending the buildId to the nuget package name.
Redgate SCA Devops build pipeline cannot overwrite the nuget package - build fails
We recently had to change out build pipeline from using LocalDB to a full SQL instance (using full text searching so need full DB to build).Since we changed the pipeline configuration, we cannot ge...
@DustinM Thanks for the reply, however it does not fully answer my question. I can filter out the entire schema of replicated tables when doing the compare, but any programmable objects that depend on replicated tables won't build in the event that the underlying tables are changed. I misspoke in my original post, as the replicated tables are in my baseline (started from an existing production database). So what I am wondering is the best way to have these objects in the schema model so that the build and release pipeline will work. From what I can tell my options are: 1. import the changes into the schema so the build works, but what happens when the release is deployed? Will it try to alter the replicated tables? (Note that they will already have been changed in the target) 2. Should I remove the replicated tables completely from my schema model and recreate them through scripts when building the project? Where would they go? In a Pre-Deployment sql file or some where else? Keeping in mind that I do not want them to be deployed, only there for the build to work. I know that they will be in my target DB when the deployment happens. Thanks in advance, Garth / comments
@DustinM Thanks for the reply, however it does not fully answer my question. I can filter out the entire schema of replicated tables when doing the compare, but any programmable objects that depen...
Concurrent releases in the SCA deployment pipeline
Here is our scenario: We currently have at least one release in progress for which we import the changes into our SCA project and it gets put into the CI/CD pipeline. From time to time, we need t...
Replicated tables in pipeline
I have a schema of master data that is replicated into all of our environments that I have excluded from my baseline. We have views that reference those tables that obviously won't build when depl...
@Nick_Foster Thanks, that's basically what we have wound up doing. A bit hacky in my opinion, but it gets the job done. / comments
@Nick_Foster Thanks, that's basically what we have wound up doing. A bit hacky in my opinion, but it gets the job done.
@Kendra_Little How would one go about disabling the validation in the SCA project? I am in the same situation but we are using SQL LocalDB on a self-hosted Agent. I have a synonym that points to another database that ultimately will be on the same server as the database being released. Thanks. / comments
@Kendra_Little How would one go about disabling the validation in the SCA project? I am in the same situation but we are using SQL LocalDB on a self-hosted Agent. I have a synonym that points to ...