Re: Solving conflicts
- From: "David W. Fenton" <dXXXfenton@xxxxxxxxxxxxxxxx>
- Date: Sat, 01 Oct 2005 14:22:40 -0500
Lothar Geyer <Lothar.Geyer@xxxxxxxxxxxxxxxxxxxxx> wrote in
news:3q6tn3Fdl6e2U1@xxxxxxxxxxxxxx:
> Lothar Geyer wrote:
>
>> ...
>> 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.
> > ...
>
> I have to add one disadvantage not using ConflictFunction: after
> conflict resolution I will have to start a second synchronization
> to distribute the resolutions.
That's right. But that's the case with any conflicts that are
resolved by the built-in conflict resolution wizard, as well.
And that's also why you are better off applying changes
field-by-field when the losing record has data you want to keep,
rather than by deleting the winning record.
Remember, the ConflictResolver function only controls what conflicts
get resolved automatically. If you have none, then you get the
default conflict resolution algorithm.
Either way, default or custom ConflictResolver function, you will
have conflicts that can't be resolved automatically, and those have
to be handled by the end user, either with the default wizard, or
with a custom UI.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
.
- Follow-Ups:
- Re: Solving conflicts
- From: Lothar Geyer
- Re: Solving conflicts
- References:
- Re: Solving conflicts
- From: David W. Fenton
- Re: Solving conflicts
- From: Lothar Geyer
- Re: Solving conflicts
- From: Lothar Geyer
- Re: Solving conflicts
- Prev by Date: Re: Solving conflicts
- Next by Date: Re: Solving conflicts
- Previous by thread: Re: Solving conflicts
- Next by thread: Re: Solving conflicts
- Index(es):
Relevant Pages
|