Comments
2 comments
-
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 -
@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
Add comment
Please sign in to leave a comment.
How can I get SCA to ignore those tables, or how should I be including those tables so that the project will build?