update sysmergepublications set generation_leveling_threshold = 0 (on the subscribers)

Is this supported? Interesting question as this solution came from the PSS folks. I suppose you'd have to open a support case with them and have them talk you through doing it for it to be supported. No hotfix as yet but I'll add an addendum when it comes in.
 

You could also set up a job to regularly poll the conflict table.

sp_repladdcolumn @source_object = 'Table3'
, @column = 'xxx'
, @typetext = 'uniqueidentifier not null default(newid()) CONSTRAINT UPKCL_Table3 PRIMARY KEY CLUSTERED'
, @publication_to_add = 'northwindtable3'
, @force_invalidate_snapshot = 0
, @force_reinit_subscription = 0

If the table has data already, there are issues of uniqueness, hence I have used the default to avoid this problem. In this case I couldn't add an Integer PK. BTW this is all relatively straightforward in SQL Server 2005 with the nice new @replicate_ddl parameter.

There are 3 options:

(1) SQL Server Upload Only Conflict Resolver. BOL: "Changes uploaded to the Publisher are rejected; changes are downloaded to the Subscriber". (set at design time for the publication)

(2) the -EXCHANGETYPE parameter (can be set at run time for the subscription)

(3) @subscriber_upload_options (set at design time for an article of the publication)

eg, consider I merge replicate the 2 tables: Customers and Orders from the Northwind database. These are joined by a PK - FK relationship - a customer can place several orders. If I create a join filter to link the tables, all 'ordering' Customers and their associated Orders are replicated.  I then add a filter clause on the Customers table (parent) to restrict the output to a particular customer: customerid = 'VINET'. The resulting (automatically created) merge view for Orders restricts the results to 5 orders - those belonging to customer 'VINET'. So, on initailization one customer and 5 associated orders are replicated. However, what if I also put a filter on the Orders table: customerid = 'ALFKI'. Logically this should further restrict the replicated Orders. However, on initialization 11 orders are now replicated. In this case the following view is created:

create view [NorthwindCustomersMerge_Orders_VIEW] 
as select alias_2C2031330F9D40AA96EB39B49AF00F41.* from [dbo].[Orders] alias_2C2031330F9D40AA96EB39B49AF00F41 
where rowguidcol in ( select [Orders].rowguidcol from [dbo].[Orders] [Orders] , [NorthwindCustomersMerge_Customers_VIEW] [Customers] 
where ( ( customers.customerid = orders.customerid) ) and ({ fn ISPALUSER('A23CFAD1-BDAC-4E0E-8447-BCD79E786943') } = 1) 
union select [dbo].[Orders].rowguidcol from [dbo].[Orders] where ( (customerid = 'ALFKI') ) 
and ({ fn ISPALUSER('A23CFAD1-BDAC-4E0E-8447-BCD79E786943') } = 1) ) 
and ({ fn ISPALUSER('A23CFAD1-BDAC-4E0E-8447-BCD79E786943') } = 1) 

I've highlighted the crucial bits in red. The first part of the view refers to the join and the NorthwindCustomersMerge_Customers_VIEW view contains the customerid = 'VINET' clause. The second part refers to the order filter, but the 2 parts are UNIONED, rather than an AND clause being used. This means that rows arriving as part of the join, but which don't have a customerid = 'ALFKI' are additionally returned! I'll verify if this also occurs in SQL Server 2005.

The question was asked with reference to the following tables:

Files table: ID, Name, Type
Documents table: ID, FileID, Name, DocPath
Type lookup table: ID, Name

(so there are many documents in each file). Before the user goes offline, he asks to "download" several files he's been working on to his laptop along with the related documents. Note that the solution to replicate all files and documents wasn't acceptable.

Changing the initializing data retrospectively isn't possible directly unless you have a separate publication for each subscriber, change the filter clause and then reinitialize. However, using static filters, it is possible to reallocate records at the highest level, and the effect will propagate downwards by virtue of the join filters. This will allow you to simulate changing the filtering dynamically. Practically speaking, there would be have to be another table ("File_Subscriber") which relates files to subscriber, and table joins would then relate the other tables, while the static filter would apply to the "File_Subscriber" table only. Checking out another file by a subscriber would be an insert into the "File_Subscriber" table. Perhaps surprisingly, merge replication will, on synchronization, replicate not only this new record, but all related records by virtue of the join table filters, so in effect, we can reinitialize each time but dynamically. I'll create an article on this interesting merge be

To test this, I used 2 tables - Region and HostnameLookup - shown below. The HostnameLookup table defines the multiple values I'm interested in. I use dynamic filters to filter the HostnameLookup table using HOST_NAME() and a join filter to join to the region table. Editing the 2nd step on the merge agent's job to include: -Hostname PaulsComputer means that only 2 regions get replicated. I've listed the exact text below in case you want to recreate it to test.

Region
RegionID, RegionDescription, rowguid
1, Eastern, 9A6377F0-70DF-4A5C-962D-B41A41EFA82B
2, Western, C0CAEFAD-7B8C-43D6-87ED-920494A5C60C
3, Northern, 6CD9AA33-BE2D-4DCF-B447-745A3B86818E
4, Southern, B4826E41-96D6-457C-8645-DD4984AE3BF5

HostnameLookup
RegionDescription, Hostname, rowguid
Northern, PaulsComputer, 2367C78A-1001-417B-A3B1-1C74B23F8131
Southern, PaulsComputer, 4F563C4D-8479-4A7D-A938-490DD514F12A


Filter Clause for HostnameLookup:
SELECT <published_columns> FROM [dbo].[HostnameLookup]
WHERE HostnameLookup.Hostname = HOST_NAME()

Filter Clause for Region:
< All rows published >

Join Filter:
Filtered table is HostnameLookup
Table to Filter is Region

SELECT <published_columns> FROM [dbo].[HostnameLookup]
INNER JOIN [dbo].[Region] ON Hostnamelookup.regiondescription = region.regiondescription

Edit the 2nd step on the merge agent's job to include: -Hostname PaulsComputer

Run the snapshot then merge agents and only 2 regions should be replicated.

This is called the "compensate_for_errors" problem. If a change from publisher fails to get applied at the subscriber (for some reason, PK,FK,CHECK,etc constraints) it undoes the change at the publisher. So a insert from publisher when fails at the subscriber gets deleted at the publisher too. Similary a delete from publisher which fails at the subscriber, it gets re-inserted at the publisher. There is an associated KB article.

Run a ping -t for a day and then look at the statistics to see if a hicup occured.

You could run this keep alive script which will tell you exactly when you get a failure. Save this as c:\keepalive.sql


WHILE 1<>2
BEGIN
SELECT GETDATE()
WAITFOR DELAY '00:00:01'
END
GO

Here is the batch file that I use to run this script:
osql -S hilary2kp -E -i c:\keepalive.sql -n
date /t
time /t

(Hilary Cotter)

This can be done by having a filter of 1=2 on the article (table). However, inserts made when the merge agent is synchronizing may not be removed.

IF Not UPDATE(extra column name)
BEGIN
existing trigger code
END

The insert and delete triggers could be left as they are, as both should
propagate through the normal merge replication

(1) Firstly when the filter was set to 1=2 and inserts were made while the merge agent was running

(2) If you bulk insert the rows and choose the defaults, then FIRE_TRIGGERS is false and consequently the rows are not added to MSmerge_contents. 

(3) If you do a fast-load using the Transform Data task in DTS:

In all cases case, you need to run sp_addtabletocontents to include the rows then resynchronise. Alternatively you can use sp_mergedummyupdate for a single row. For the fast load case, in future if you deselect the check box the triggers will fire.

(a) in the case of HOST_NAME() there is a parameter for the replication merge agent - HOSTNAME - this can be set to be different from the computername, and so could be a business-related value. NB there is no corresponding SUSERSNAME parameter.

(b) We can also use a user defined function: eg MyUDF(SUSER_SNAME()). This function is coded to use a lookup table which map logins (or computernames) to a key column in the replicated table.

(a) modify the insert trigger on the subscriber to ensure it doesn't write the changed record to MSmerge_contents.

(b) use partitioned views to partition your data based on the original merge replication filter and only replicate one table.

This is not so obvious as it first seems! Firstly, when you configure merge replication, you choose global subscriptions (priority numbers) or local subscriptions (first subscriber gains priority of Publisher). There are 3 combinations:

(a)     Just global subscriptions. Highest value wins and publisher always wins.

(b)     Just local subscriptions. First subscriber wins and publisher always wins

(c)     Both local and global subscriptions. If local merge agent synchronises first, he wins. If global synchronises first, he beats any locals and then competes as usual with any other globals.

(a)     Just local. Change the same row at each subscriber. Synchronize Subscriber1 and then Subscriber2. The second synchronization will register a conflict and explain that Subscriber1's value wins.

(b)     Global. Consider that subscriber1 has a priority of 75 and subscriber2 has a priority of 50. They both change the same record. If Subscriber1 synchronizes then Subscriber2, there is a resolved conflict. However, if Subscriber2 synchronises first then Subscriber1, the value is overwritten and no conflict registered. It is only when Subscriber2 resynchronises that a conflict is registered. So, the rule is that a conflict occurs only when a lower valued (priority) subscriber tries to overwrite a higher valued one.