"John" <Jo**@nospam.infovis.co.ukwrote in
news:La******************************@pipex.net:
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_DataSource 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_Conflicts, 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/