Replication conflict Viewer question

I have suddenly gotten several replication conflicts where in the
winning conflict box, the following is shown:

"This row contains data that violates a table or fields level validation
rule that was added at the design master, after the time the data was
inserted into the replica. You may either change the data to meet the
new validation rule, or you may ignore the conflict."

I tried once to accept the losing conflict but found it was missing a
required value.

Suggestions on what is happening?

Bob

Re: Replication conflict Viewer question

Bob Alston wrote in
news:g%waj.91$e56.34@newsfe06.lga:

> I have suddenly gotten several replication conflicts where in the
> winning conflict box, the following is shown:
>
> "This row contains data that violates a table or fields level
> validation rule that was added at the design master, after the
> time the data was inserted into the replica. You may either change
> the data to meet the new validation rule, or you may ignore the
> conflict."
>
> I tried once to accept the losing conflict but found it was
> missing a required value.
>
> Suggestions on what is happening?

Well, the explanation seems quite clear to me -- you tried to
propagate a validation rule to replicas whose date did not conform
to the new validation rules. The conflict is telling you that a
record has been edited in a replica where the data conforms to the
validation rules and in another replica where it *doesn't*. Change
the data in the winning record to conform to the validation rule and
accept it and the problem should vanish.

But there's key lesson here:

When making schema changes that affect validation rules and/or
relational integrity, the first thing you should do is synch all the
replicas so they have identical data, then edit the data to conform
to the new validation/RI rules, re-synch around the whole replica
set, and only *then* implement and propagate the validation/RI
changes.

I see people making this mistake all the time because they don't
understand the order in which such changes are implemented. You have
to be very granular about this kind of thing. Not doing so can cause
permanent errors that can't be fixed without rebuilding the affected
tables from scratch.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/