Merge replication is taking place between hand held clients running
SQLServerCE (anonymous subscription) and a SQL Server 2000 box. We
have a stored proc that executes nightly (scheduled job) archiving
records older than 90 days on the SQL Server 2000 database. What we
have been finding is that users that have collected data prior to this
nightly job will have increased volume of data transmitted during their
merge replication at the end of the next day. It seems that when
performing the merge of data, the server is transmitting to the
subscribers info about the records archived overnight. Is there any way
to stop these deletions being sent to subscribers, as users merging
info over dial-up are taking extremely long times to complete updates
under these increased volume conditions.
With transactional replication a stored proc may be written and
replicated to the subscribers to delete the archive records on the
devices. This replaces the need to send hundreds of individal
transaction deletion rows to the subscribers.

Can anyone help in outlining the best way of achieving this in a MERGE
replication suituation.

Thanks in advance

Please take a look at the parameter @delete_tracking. Execute
sp_changemergearticle (Transact-SQL) at the Publisher on the publication
database. Specify a value of delete_tracking for @property, and a value of
false for @value. This looks like what you need.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com

Paul, out of interest.
Is there a way to apply these settings without needing to delete and
re-apply the publication script?
There is really no single point in time when all data from units are
merged. If we remove and re-establish publication whilst we have
outstanding non-merged units in the field. we lose the ability to sync
these units.
Thanks

[quoted text, click to view]