Re: Solving conflicts

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi David,

as I am a German citizen and my English is not very well, I want to go sure not to misunderstand you:

David W. Fenton wrote:
Lothar Geyer <Lothar.Geyer@xxxxxxxxxxxxxxxxxxxxx> wrote in
news:3q5cejFd68s8U1@xxxxxxxxxxxxxx:

I'm using Access 2000 with an VB 6 app and want to create my own conflict resolver. I have two questions:

1) do I have to use the ConflictFunction property to replace the standard conflict viewer? I would prefer to call my resolver sub
after normal synchronization. 

If you are implementing your own conflict resolution rules, as
opposed to simply implementing a new UI for the default rules, then
you really ought to set the ConflictFunction property so that you
won't run the risk of having conflicts resolved with two different
rule sets depending on how it's done.

Documentation says that a ConflictFunction has to solve all possible conflict situations. However, I can't do that. There are a lot of conflicts where I can decide which record will be the winning one. With other conflicts I need a user decision. To get this I will have to display additional information to the user. E.g. in a table "OrderItem" there is a pointer to table "Items". The user may need to know the item name for his decision, not only the autovalue assigned to the item.

So I would like to keep the standard solver. After synchronization finished I call a procedure to solve all conflicts where I don't need user decisions. And in the last step I open a form and display all data the user needs to take his decision.

May be that's because I do not really understand the ConflictFunction as I did not find any samples. I do not know what to do in that function. Obviously it is called whenever a conflict is found during synchronization. First: I did not found any information where to find conflicting records. Second: What to do with these records?


2) when my resolver decides that the winning record should remain
the actual one I only have to delete the loosing record in the
conflict table. If the loosing record should become the actual one
I have to delete the winning record, then copy the loosing record
from the conflict table as a new record to the "normal" table,
then delete the loosing record from the conflict table. Do I have
to copy _all_ fields including the fields added by replication
(s_Guid a.s.o.)? Or do I have to copy the "normal" fields from the
loosing record to the winning one (so not creating a new record)?

Hmm. Deleting the record seems rather drastic, as if there are child
records, those get deleted, too (assuming you've got cascade deletes
on), or you own't be able to delete it at all (if you've got cascade
deletes OFF). 

OK.

Why not just copy field-by-field, and change only the fields where
the data does not match? This can be done easily by looping through
the Fields collection of a recordset and testing: 

   Nz(rsConflict!Field) = Nz(rsLosingRecord!Field)

Now, obviously, you'd do that differently depending on the field
type, but basically you only need 2 tests, one for text and numeric
fields, one for date and Boolean fields. The former uses Nz() and
the latter doesn't.

As to the replication fields, you don't want those values edited, so
if you're appending (as I believe I've explained you should not),
you would append only the data values so that Jet can set the values
in the replication fields appropriately.

To reiterate: I'd copy, not append, and copy only the values that
aren't the same.

I understand. If the winning record wins I have to do nothing. If the loosing record wins I have to copy the fields from the conflict table to the actual table.
Why should I test for matching fields? I assume this takes more time than just copying the field value.

As I am using column tracking, I assume there are pointers to the conflicting column(s) in a record? Where can I find these? This would be the best way to copy only data which is necessary.

Now - after application data is fine: what to do with the conflict data? Do I have to
- delete the loosing record in the conflict table?
- delete the conflict table when empty?
- delete conflict entry in MSysConflicts?
- what else?
- or is there another way to tell Jet that this conflict is solved and Jet does necessary cleaning?

Lothar Geyer
.

Relevant Pages

  • Re: Solving conflicts
    ... > conflict resolver. ... If the loosing record should become the actual one ... you would append only the data values so that Jet can set the values ...
    (microsoft.public.access.replication)
  • Re: Solving conflicts
    ... >> If you are implementing your own conflict resolution rules, ... rules and the conflict resolver -- it obviously doesn't resolve all ... After looking through the replication ... If the loosing record should become the actual ...
    (microsoft.public.access.replication)
  • Re: Solving conflicts
    ... > 3) Is it OK that after deleting the record in the conflict table ... Jet 3.5, so I've never had to deal with it. ... The purpose of MSysConflicts is to distribute information about ... conflicts from any replica in one place. ...
    (microsoft.public.access.replication)
  • Re: Solving conflicts
    ... - deleting a record in a conflict table also deletes the corresponding entry in MSysConflicts. ... conflict tables are not deleted by the standard conflict viewer after alle entries are deleted. ... Jet 3.5, so I've never had to deal with it. ... conflicts from any replica in one place. ...
    (microsoft.public.access.replication)
  • Re: Cant clear sync error
    ... I'm using Jet 4.0, ... is it ok to just delete records in the conflict table? ... re-spawned replicas from the design master so there shouldn't be any real ... have conflicts and would I like to resolve them. ...
    (microsoft.public.access.replication)