Replication gone crazy

[John]

Hi

When I try to resolve replication conflicts, first of all 'Microsoft
Replication Conflict Viewer' gets stuck for 15-20 seconds then it gives the
error 'There was an error trying to obtain data for a specific conflict
table for 'MyTable'. The viewer can not display this conflict.". In the log
file I get the following two types of entries;

Database Publication Table Origin_DataSour ce RowGuidValue conflict_type
reason_text

F:\MyDB.mdb (Not Specified) MyTable C:\MyDB.mdb
{1BCC3F03-5972-4F9B-A88E-903B08F86FC0} 3736 Update/delete conflict. This
updated record was deleted at another replica. Either reinsert this conflict
record or delete it.

F:\MyDB.mdb (Not Specified) MyTable {1BCC3F03-5972-4F9B-A88E-903B08F86FC0}
3736 Update/delete conflict. This updated record was deleted at another
replica. Either reinsert this conflict record or delete it.

Any idea what is wrong and how can I fix it?

Thanks

Regards

[David W. Fenton]

Re: Replication gone crazy

"John" <John@nospam.in fovis.co.ukwrot e in
news:LaOdnXB1i6 a9NaXYnZ2dneKdn ZydnZ2d@pipex.n et:

When I try to resolve replication conflicts, first of all
'Microsoft Replication Conflict Viewer' gets stuck for 15-20
seconds then it gives the error 'There was an error trying to
obtain data for a specific conflict table for 'MyTable'. The
viewer can not display this conflict.". In the log file I get the
following two types of entries;
>
Database Publication Table Origin_DataSour ce RowGuidValue
conflict_type reason_text
>
F:\MyDB.mdb (Not Specified) MyTable C:\MyDB.mdb
{1BCC3F03-5972-4F9B-A88E-903B08F86FC0} 3736 Update/delete
conflict. This updated record was deleted at another replica.
Either reinsert this conflict record or delete it.
>
F:\MyDB.mdb (Not Specified) MyTable
{1BCC3F03-5972-4F9B-A88E-903B08F86FC0} 3736 Update/delete
conflict. This updated record was deleted at another replica.
Either reinsert this conflict record or delete it.
>
Any idea what is wrong and how can I fix it?

Between synchs, a record was updated in one replica and deleted in
another.

This oughtn't be a problem, but something has gone wrong.

Check the records involved in the replicas identified and see what
you can see. Should the record have been deleted? If so, you can
discard the updated version and leave it alone. You can confirm this
by checking the conflict table for the table in question (it will be
called MyTable_Conflic ts, and will be marked HIDDEN, so you'll need
to go to TOOLS | OPTIONS and turn on display of hidden objects;
while there, you might as well display system objects, because you
may need to use the replication system tables, as well). Using the
RowGUIDValue, you can check to see if the record was in fact deleted
from MyTable. If it was, there won't be any row with s_GUID set to
that value. If there *is* a row with that value, it means the record
was *not* deleted.

The log file most likely has two entries because you have synched
twice (either with the same replica or with two different replicas)
-- both entries refer to the same record (the GUID is the same) and
the same error type.

Now, if the record should *not* have been deleted, then you'll need
to add it back by appending the version of the record in conflict
table to the main table, but ignoring all the replication fields.
That will create a new record with the same data but it will be a
new record from Jet replication's point of view.

Once you've resolved this issue, you can delete the conflict record
from the conflict table (or the whole conflict table if there are no
other conflicts).

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