Summarised: Filtered record, changed at Publisher to take out of filter for Subscriber, at Subscriber record removed but related records dont go, bad.. Alternatively, Filtered record, changed at Subscriber to take out of filter, Replication removes all related records from Subscriber db when merge repl runs, good... :-|
Why the difference?
Have Row Filters & Join Filters.
Details: Ive set up Merge replication, with several articles with Row/Join Filters.
When I change a record on the Publication that exists at the Subscriber (that has been filtered/sync etc) that record gets communicated to the Subscriber, which is fine.
However, when I change a record on the server so that the record is no longer valid for that Subscriber because it falls outside the filter - the delete goes to the Subscriber, but its related records on the Subscriber do not get removed.
This is even more confusing, because if I change the record at the Subscriber, so that it falls outside the filter, it gets removed along with its related record.
Ive checked the logic & relations/joins which all appear to be valid. The fact that the Subscriber removes related records when it changes the record suggests that the Joins are valid. Doesnt it?
Is there an option/flag to force server changes to validate related records when sync happens?
Any help much appreciated.
Mr Le.Anybody, anybody? ;-)
Ive checked other posts in here and there appeared to be a couple of other people who had a similar issue, im following those threads to see if they offer a solution or hint.
Thanks for reading.|||Mr Le,
please can you post up a little more info. Are you adding rows on the
subscriber? Are these rows being propagated to the publisher but then not
removed on the subscriber as you'd expect due to the filter? If this is the
case I know of 2 posibilities:
(1) you've done a bulk insert without firing triggers on the subscriber.
(2) you have a filter like 1=2 and have added records while the merge agent
is running.
In each case you can:
run SP_ADDTABLETOCONTENTS then synchronize
run SP_MERGEDUMMYUPDATE for a single row then synchronize
HTH,
Paul Ibison
|||Paul,
Thanks for replying, its much appreciated, hopefully I can add a bit more info to clarify whats happening.
The Subscriber is a Pull-Subscription.
There are Row/Join filters defined for the Publication.
The initial Snapshot took a subset of records from the Publisher to the Subscriber, that were in-line with the filters defined for that Publication.
Test 1
1. The subscriber receives the Snapshot, and all expected records are added.
2. An update to a row at the Publisher is propogated to the Subscriber, where it is deleted because it no longer satisfies the Filters.
* Related records are not removed from the Subscriber though. This is the Problem.
* So we tried to see what would happen if we changed the record at the Subscriber instead of the Publication.
Test 2
1. We reinitialized the Subscriber, the initial Snapshot was then applied to the Subscriber. All valid records go across.
2. This time, we changed the row at the Subscriber, and this change meant that the record no longer satisfied the Filter. Merge Agent ran, and deleted the record on the Subscriber, except this time it also deleted all related records, which is what we expected to happen in the first place.
These "deletes" were not propogated back to the Publisher, which again is what we expected.
* No Bulk updates/inserts took place, other than those caused by the initial Snapshot.
* No records were added whilst the Merge Agent was running.
Hope ive described this well enough.
If you need more detail of the row filters were using and/or join filters, let me know.
Thanks again for your help.|||Mr Le,
thanks for the detailed description. Please can you post up a schema of the
tables involved and details of the joins/filters involved, and I'll
reproduce it here.
Cheers,
Paul
No comments:
Post a Comment