Hi, I like this article very much, because it gave me lots of practical info I could not find elsewhere.
I would like to now more about the setup of the “DROP IF EXISTS” topic. Because I could not info about this.
Greetings Marc
SSDT includes the ability to do a pre-deployment script, and the original thought was that whenever dropping a table we would add a line into this script "DROP TABLE IF EXISTS _____".
Since then we've adjusted a bit, instead of deleting tables or columns outright we move them into a "deprecated" schema for a while (or append "_deprecated" to the column name), then once a quarter we do a higher risk deploy where we delete all of the deprecated objects, and do a deploy with the data loss prevention mechanisms turned off and "Drop objects in target but not in source" enabled.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, I like this article very much, because it gave me lots of practical info I could not find elsewhere.
I would like to now more about the setup of the “DROP IF EXISTS” topic. Because I could not info about this.
Greetings Marc
SSDT includes the ability to do a pre-deployment script, and the original thought was that whenever dropping a table we would add a line into this script "DROP TABLE IF EXISTS _____".
Since then we've adjusted a bit, instead of deleting tables or columns outright we move them into a "deprecated" schema for a while (or append "_deprecated" to the column name), then once a quarter we do a higher risk deploy where we delete all of the deprecated objects, and do a deploy with the data loss prevention mechanisms turned off and "Drop objects in target but not in source" enabled.