Activity overview
Latest activity by Andrej
Got my hands on a SQL Server 2016 machine, and SQL Compare 13 would also first drop the clustered columnstore index before dropping the table (see my scenario above). This could be a HUGE problem for a table with a lot of data (and table with a clustered columnstore index usually have a lot of data).
So be extremelly careful, study the generated script and test your deployment script on a database and a server similar to your production (yeah, Captain Obvious [image] ). It would be even better if Red Gate would correct/optimize this. / comments
Got my hands on a SQL Server 2016 machine, and SQL Compare 13 would also first drop the clustered columnstore index before dropping the table (see my scenario above). This could be a HUGE problem f...
Thanks for quick answers, guys.
In my situation it's indeed the verbosity what hurts most. When preparing the deployment, I usually take the generated script as a first “prototype” and adjust it manually because SQL Compare obviously can’t know everything (for example, how I want to do some specific data migration steps). The more unnecessary stuff I have in this “prototype”, more time I need to spend reading the script.
I can also imagine a situation when this SQL Compare behavior can present a real performance problem. This requires SQL Server 2016/2017 which I unfortunately don’t have at the customer site, so just a mental exercise on my part:
As you see, SQL Compare also drops the clustered index which contained the column with the FK constraint. Now imagine my table had a clustered columnstore index (and a FK. This works up from SQL2016). If SQL Compare would also drop the clustered columnstore index like in the example above, that could be quite a problem. Not only this operation is very time consuming (unpacking all the columnstore data and persisting it in a heap), but it also requires humongous amounts of data, because clustered columnstore compression is usually quite good (between 10x to 20x) and would fail if not enough space is available. Quite anecdotal if you try to free some space by dropping tables which are not needed anymore [image]
I would really appreciate if you could confirm or correct me at this point. / comments
Thanks for quick answers, guys.
In my situation it's indeed the verbosity what hurts most. When preparing the deployment, I usually take the generated script as a first “prototype” and adjust it ma...
Unneccesary steps in the deploy script when dropping a table
Hello everybody,
When dropping a table with a foreign key constraint, SQL Compare generates a deploy script which first drops the constraint, then the index (on the column where FK was defined) and...