|
I am using merge replication in SQL 2012. When I bulk insert rows into a table, and run this stored procedure to add references into the merge tracking table, sp_addtabletocontents Is that missing out on precomputing the partitions using the precomputed partition optimisations? |
|||
|
|
|
Intriguing question... as long as you have an actual scenario to apply it to it wouldn't be too difficult to figure out. Perform your BCP process, run According to this technet article that is where the partitioning data for each row that has been changed is stored post change/pre sync. Look into the article for deeper information and the manner in which the table structures are organized within the process. The link provided is for SQL 2008 but if the table structure is the same its a safe bet that the pre-compute logic is close enough to answer your question. I am not an expert on precomputed partitions but it seems to me that it would have to take advantage of the precompute process (if enabled) otherwise it wouldn't sync these records at all. |
|||
|
|
|
Thanks RThomas it looks all good. I found a table which had records added previously using BCP. After BCP had been run the 'sp_addtabletocontents' stored procedure had been used. I joined that table to the MSmerge_current_partition_mappings table, and found that some items in my table didn't have a corresponding MSmerge_current_partition_mappings record. It seemed fishy, but the reason was very simple. The records in the table corresponded to a partition that no longer existed. I added the partition back in and closing the publications properties dialog took a while (it would have been adding the new MSmerge_current_partition_mappings records). After that was done I could see that all records in my table had a corresponding MSmerge_current_partition_mappings record. It all checks out. |
|||
|
|
