Comments
4 comments
-
Thanks for your post.
Would you be able to send me a screenshot of this? As far as I know, when you set the compression on a clustered index, it sets the compression for the table. Since the table can only have one clustered index, it can only have one compression state.
I believe this is why we only compare the compression state of the table at the table level, and ignore the compression state of an index. -
Chris, it is possible to compress the clustered index and then selectively compress nonclustered indexes as desired - altering the compression state of the clustered index does not affect the compression state of the nonclustered indexes.
Likewise, any new nonclustered indexes that are created after the clustered index has been compressed are not compressed by default and have to have the DATA_COMPRESSION option included explicitly if compression is required from the outset.
Unfortunately I'm unable to replicate the exact problem that I was experiencing before as the databases have moved on since then.
Thanks
Chris -
Chris, I've sent an email (to the support@red-gate.com email address) which includes a set of files that should allow you to partially recreate the problem.
Please let me know how you get on.
Thanks
Chris -
Thanks for your help reproducing this.
I've experienced the same symptoms now, and it seems that when working with scripts, the compression state of the nonclustered indexes are ignored. Even though the setting is written to the file, it isn't considered in the comparison.
I've created bug SC-5113 for this. It also looks like this issue should be fixed in the next release of SQL Compare, but I haven't got an exact timeframe for that at the moment.
Add comment
Please sign in to leave a comment.
Furthermore the synchronisation script includes statements to change the setting of the DATA_COMPRESSION option even though the table is not selected for synchronisation (the table can't be selected as it appears under the 'identical objects' area).
I would expect a difference in the DATA_COMPRESSION setting to cause SQL Compare to highlight that there is a difference between the tables.