sql server replication: Hello

I have a merge replication problem has been driving me nuts for the last couple of days and I haven't been able to find any information on it from other posts in this group. The problem is that extra uploads (as UPDATEs) are being sent to the publisher when the subscriber sync's.

First off our setup info
Server:
- SQL Server 2000 Enterprise (SP3)
- Running on a clustered Win 2000 server (Active/Passive)
- Publisher and Distributor are located on the same virtual Sql Server instance
- Merge publication using dynamic horizontal data filters with join filters off of filtered tables
- Dynamic snapshots used for each subscribers data initialization

Client: MSDE (SP3
- Running Win XP Tablet Edition
- Anonymous on demand subscription

Table Info
Primary Table: Retailers (PK ApplicationNumber char(7)
Sub Table: RetailerInformation (PK ApplicationNumber char(7), which is also a FK to Retailers.ApplicationNumber
Replication Info Table: ReplicationRetailers (PK ApplicationNumber char(7), UserLogin varchar(20) (This is the windows login returned by the SUSER_SNAME() function during the filtering during the sync)

Publication Info
ReplicationRetailers table has a dynamic filter of 'WHERE UserLogin = SUSER_SNAME()
ReplicationRetailers Join Filters Retailers on ApplicationNumbe
Retailers Join Filters RetailerInformation on ApplicationNumbe

Our replication is working great; the correct data is being sent down to the subscribers database, speeds are excellent, etc... However we noticed a strange behavior while testing yesterday. If I assign a new retailer to a user (by adding a row to the ReplicationRetailers table) the first sync down to the subscription works fine; all the applicable Retailer records are INSERTed into the subscriber. However, when the subscriber sync's again, an almost identical number of UPDATEs are sent back up to the server. The number of UPDATEs never quite equals the number of INSERTs but is usually 2-4 less. The data that gets UPDATEd up to the publisher is not different from the data that was INSERTed to the subscriber and I know that there are no subscriber table triggers firing that update any data

I've traced the merge process to see what tables are sending data back up to the publisher and confirmed that it is the Retailers table and its associated sub table that sends the updates. However I cannot tell exactly which records are being sent

I know this is not the normal behavior during a sync as I have other tables that have an identical table filter that only send data when there are changes (in the same publication). So I guess I have a couple questions
1) Has anyone else seen this behavior
2) Is so, what did you do to fix it
3) Is there some way to use the MSmerge_contents and MSmerge_genhistory tables to figure out what rows are going to be sent durning the next sync BEFORE the sync occurs

Thank you very much for your help

Each row in a merge published table has a GUID column which is used to uniquely identify each row

Each row in MSmerge_contents corresponds to changes which have happened locally on the database.

Each row in MSmerge_contents will contain an generation number

When the merge agent runs compares the generation numbers in in MSmerge_contents and the msmerge_replinfo table between the publisher and subscriebr to determine which GUID's have incremented their generation number

Then depending on whether the publisher or subscriber has the higher generation number a stored procedure is constructed with parameters based on the values in either the publisher or subscriber published tables and executed on the subscriber or publisher

To directly answer your question, you will have to look at both these tables to determine which article is generating these phantom transactions

Profiler will be handy in resolving this

Looking for a SQL Server replication book
http://www.nwsu.com/0974973602.htm