If I edit the same field in the same record at the same time on databases remote to each
other, I wind up with a condition where the records cross stream, and each database has
what was entered on the other side, but they do not agree. If I edit two different fields
on the two copies, the result is comical, with exactly 1/4 of the changed information
going anywhere. Whether I pull and then push, or push and then pull, the results are
identical.

Comments appreciated.

I have a reasonable workaround, where I have triggers stamping records so that I know
which updates should be rejected. However, it looks like if I reject a row from an update,
then the entire update bombs out. Is it possible to reject selected rows from an update
without a tedious column by column unwind of the changes in a before update trigger?

Ignore the first two posts, I've moved past them.

However, the absolute simplest case of replication is falling over and I'm baffled as to why.

A single published table on two database servers. I edit one single record on the 1st
computer and do no more editing of any kind. When I save updates, I see in the
uncompressed change log that publish ID {5B...} has seen the record. I load the update
into the 2nd computer and save updates, I see in the uncompressed change log that publish
IDs {5B...} and {0F...} have seen the record. I load this update into the 1st computer and
save updates, oops, I see in the uncompressed change log that only publish ID {5B...} has
seen the record. When I load this update into the 2nd computer, I'm not shocked to see an
exception talking about a primary key violation.

I can't come up with a simpler replication scenario to try to troubleshoot why this isn't
working. 2.02B10.

Well I created an empty error insert trigger and it seems to be swallowing the exception.
Still have no idea why the manifests aren't identical going both directions on an
unchanging table.