Large Table & Merge

I added a large table to our merge pub, 3.4 million rows. Snapshot ran
rather fast, merge agents pushed rows out to 7 subscribers quickly. All
looking ok. Begin testing. Inserts at subscriber not being replicated. Look
at merge agents, change profile to Verbose. They are all displaying 0
inserts, 100 updates, 0 deletes, 0 conflicts.
Run profiler at subscriber and see the following being executed by merge
agent:
exec sp_MSproxiedmetadata 1708016, 'EACC4DE0-9FAC-420A-A4C4-1569768E01CC',
0x3CE7F05C01000000FF, 0x3CE7F05C010000003CE7F05C01...
Is this part of the synch process? Is a 3.4 mill row table WAY TOO BIG to
add to merge?
Any help much appreciated.
Thanks.
Chris
Yes it is. Basically this is the option to minimize network traffic by using
additional storage at the publisher. The publisher tracks where each row has
come from and has to tag the msmerge_contents table with this info.
However, I think you need to use the conflict viewer to understand what has
happened to your inserts.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Chris" <Chris@.discussions.microsoft.com> wrote in message
news:E058091C-50EB-4D09-8758-2F6A6E7D9785@.microsoft.com...
> I added a large table to our merge pub, 3.4 million rows. Snapshot ran
> rather fast, merge agents pushed rows out to 7 subscribers quickly. All
> looking ok. Begin testing. Inserts at subscriber not being replicated.
> Look
> at merge agents, change profile to Verbose. They are all displaying 0
> inserts, 100 updates, 0 deletes, 0 conflicts.
> Run profiler at subscriber and see the following being executed by merge
> agent:
> exec sp_MSproxiedmetadata 1708016, 'EACC4DE0-9FAC-420A-A4C4-1569768E01CC',
> 0x3CE7F05C01000000FF, 0x3CE7F05C010000003CE7F05C01...
> Is this part of the synch process? Is a 3.4 mill row table WAY TOO BIG to
> add to merge?
> Any help much appreciated.
> Thanks.
> Chris