Article ID: 241678 - View products that this article applies to.
This article was previously published under Q241678
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 56460 (SQLBUG_70)
By design initial synchronization of existing data rows, on the publisher, that do not meet established filter criteria are not moved to the subscriber. However, some modification sequences making the filter criteria valid for a subscriber, after synchronization, can lead to only partial data merge on the subscriber.
Merge replication keeps track of changes to rows using a system of GUIDs and change track tables. Any modification immediately ties the associated ROW GUID to a merge replication tracking table. The behavior of this issue is such that any modified row(s) will be merged but subsequent rows meeting the filter criteria that where not modified, are not merged. Any modification contained in the tracking table is properly evaluated during the merge process.
A temporary table is used to track merge filters requiring evaluation as a result of a given modification. This table did not contain the information necessary to identify the subsequent filters requiring evaluation.
Microsoft has confirmed this to be a problem in SQL Server 7.0. This problem has been corrected in U.S. Service Pack 2 for Microsoft SQL Server 7.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
254561For more information, contact your primary support provider.
(https://support.microsoft.com/kb/254561/ )INF: How to Obtain Service Pack 2 for Microsoft SQL Server 7.0 and Microsoft Data Engine (MSDE) 1.0
The issue corrected by the fix pertains to filter and sub filter qualifications. The merger replication process allows the user to establish an elaborate system of filter operations to segment data for given subscribers. It is possible to have a sequence of modifications made at a publishing site extending qualification of filter criteria that did not exist at initial synchronization time.
For example the STORES table is a primary key table containing basic store information such as location. The EMPLOYEE table is a foreign key table to STORES establishing a work relationship for the EMPLOYEE. Finally, you have a DIRECT_DEPOSIT table as a foreign key reference for each EMPLOYEE.
The replication filters are partitioned in a manner so each store pulls its own employee data. During initial synchronization Bob works for STORE ID #100. STORE #100 gets the proper data for Bob.
A brand new store, STORE #200, is being built and Bob is going to transfer because it is closer to his house. The sequence of conditions to encounter this issue would be:
The correction successfully applies the filter to the DIRECT_DEPOSIT table and move the detailed row to the subscriber.