Replicated tables in pipeline

Garth_Martin

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 deploying through DevOps.
How can I get SCA to ignore those tables, or how should I be including those tables so that the project will build?

DustinM

Hello Garth,

Thank you for your inquiry into SQL Change Automation.

There is a way of having SCA ignore/filter out table results, the article below provides the steps on how to do so using SQL Compare to create the filter file.

https://documentation.red-gate.com/sca/developing-databases/concepts/filtering

I hope this information helps.

Best,

Dustin 

Garth_Martin

@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