We have a database in two different environment with a large partitioned table. The table has 5 indexes on it, 4 which are partitioned on one field, 1 which is partitioned differently. This was done in order to support specific query patterns.

When observing the table in the system views, all partitioning and indexing matches, however SQL Compare (10.4.8.87) is showing the tables as partitioned differently. Running the following query provides the index/partition key combinations and shows them as matching across environments:

I'd be happy to help if you could provide examples on what's different in your case/shouldn't be different. It's not using a single query for this.

Also it would be useful to know if you see the problem as an identical object being scripted in the synchronization, or being shown in the results of the comparison, as the two sets use different logic (and sometimes the visual differences do not accurately reflect the comparison result).

I'm struggling with how to make this clear. Have you reviewed the repro script I attached to the second ticket(#4457)? As stated in the original post, we've created the same table in two different databases (one in each of our environments). Both tables were created with exactly the same SQL statements, partitioned the same way on the same fields as described in the initial post. SQL Compare, when reviewing the different tables (one in each environment) shows the two tables as being different when they're not, as validated by the system views query I posted initially.

We would like to know why SQL Compare is incorrectly reporting a difference. Please let me know what I have not made clear.

Problem is SQL Compare starts getting confused about which field is going to serve as the partition field when you have a table on a partition scheme and have multiple indexes on the table. Removing the nonclustered index [IX_ContractOrgItem_2] from the table creation script you sent results in SQL Compare using the correct ContactOrgId as the field used in the partition scheme that the table is on. The bug reference number is SC-6590.