Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

up vote 1 down vote accepted

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 sp_addtabletocontents and then before the subscriber syncs verify the existence of the records in the MSmerge_current_partition_mappings and MSmerge_past_partition_mappings tables.

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.

share|improve this answer
    
OK. That sounds perfect. I will try it out. –  peter Oct 10 '12 at 2:24
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.