May 2, 2024 at 4:14 am
Comments posted to this topic are about the item Truncate tables where Referential Integrity exists
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs"
May 15, 2024 at 2:22 pm
This seems like a very dangerous thing to do from a data governance standpoint. Won't you leave abandoned keys in related tables this way?
Ted Seeber
I find your secrets in your data.
http://www.informaitonr.us
May 15, 2024 at 4:08 pm
the code creates the drop commands and the create commands, it's for dev use so test it first to ensure it does what you require
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs"
May 2, 2025 at 7:35 pm
The idea is good. However, order of executing generated scripts is important. When you DROP constraint, the its definition is lost, there will be no way to generate ADD CONSTRAINT.
For safety sake, I would use this order of executing blocks:
Where I work, we have been using this approach for a while, to clean up tables in DEV or QA environment.
Zidar's Theorem: The best code is no code at all...
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy