http://www.replicationanswers.com/MergeNonConvergence.asp
(7) Using Joins with Multiple Filters
I'm sure filters and joins are where the complication and confusion of merge lies. Here is another example for this article: if you have a join filter between 2 tables, and a different static table filter on each table in the join, the results are not filtered correctly, or at least not at all intuitively.
E.G. consider 2 tables: Customers and Orders. These are joined by a PK - FK relationship on CustomerID so that as we'd expect 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 = 'Joe'. The resulting (automatically created) merge view for Orders restricts the results to the orders belonging to customer 'Joe'. So, on initialization one customer and his associated orders are replicated. However, what if I add another filter now to the Orders table: CustomerID = 'Harry'? Logically this should further restrict the replicated orders and we'd expect zero records returned. However, on initialization we find that more orders are now replicated! In this case the merge view is created which UNIONs the 2 clauses, rather than using a logical AND clause! This is quite different to the above scenarios - we now observe extra rows rather than seeing rows unexpectedly deleted.
This sounds like *exactly* what I need.
(This is oversimplified, but an example).
I have 150 locations that are subscribers, all with a LocationId. There are three tables involved, ClientLocation, Client, and Invoice. Each client can have multiple ClientLocation records, that is used to determine where a Client record is replicated out to. So, my filters are: ClientLocation is a parameterized filter on LocaitonId using the HOST_NAME() of the subscription (so each location gets their own ClientLocation records). The Client table is then a JOIN filter to ClientLocation so that each Client record gets replicated out to wherever the matching ClientLocation records do. The Invoice table is then a JOIN filter on Client so that each Invoice gets replicated out to wherever the Client records do. This is simple enough, and works no problem.
The wrench in my system is that each of the 150 locations can look up clients from other locations other than their own. They can then create an invoice for that Client, even though that Client isn't a record at their local database. So, the Invoice table also contains a "CreatedAtLocationId" that matches the location that created the invoice. So, the Invoice table needs two filters, it needs to be sent out anywhere that the Client record is (JOIN filter), and it also needs to be sent out to any location that matches CreatedAtLocationId (Parameterized filter), even though the Client record may not be in that subscription location, the Invoice has to be.
In my situation, I need exactly what Paul Ibison describes, a UNION of two filters (even though he was expecting an AND condition). I have tested this scenario and it works exactly as I would expect (so far, with very very limited testing).
My problem is what I found in MSDN:
http://msdn.microsoft.com/en-us/library/ms152478.aspx
The article should only have one parameterized filter or join filter. Having a parameterized filter and being the parent in a join filter is allowed. Having a parameterized filter and being the child in a join filter is not allowed. Having more than one join filter is also not allowed.
In my situation, Invoice is a parameterized filter, as well as the child in a join filter (to Client). So, what Paul Ibison's article describes, and what I'm doing seems to be 'not allowed'. If I go ahead with this, and I need this replication logic in about 6 articles out of 60, it seems risky if behaviour changes in a newer sql release or patch. Is anyone familiar with this rule? Have they done it before? Am I headed for doom?
Thanks,
Kevin