Re: Unexpected problem with synchronisation
- From: "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 23 May 2006 18:58:02 -0500
"Dave G @ K2" <DaveGriffiths70@xxxxxxxxx> wrote in
news:1148393708.623609.39690@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
David
Firstly, the reason I used an unbound form in this particular
application was - well I can't actually remember now. But I do
remember that I went through the pain of converting from bound to
unbound, and I was glad I did because it solved all my problems,
whatever they were at the time. Generally I feel that I am in
better control with unbound forms despite the extra effort.
I think my example of null was a red herring. Please ignore.
Here's the problem again as reported by the client:
1) Synchronise replicas
Are you talking about replicated Jet databases?
2) In the replica (ie on a laptop) make a change to a field in
the carer table. e.g. change the surname of a carer.
3) Close the record.
4) On the base station open up that carer record and close it
without making any changes.
5) Synchronise replicas
The data on both the replica and the base station will now be
without the change made to the replica. It seems that the opening
and closing of the record without changes wins the synchronisation
conflict with the previously changed record.
You're now talking about something else entirely.
The resolution of replication conflicts follows strict rules. In Jet
3.5, it was "least decisive user wins" (i.e., the record with the
most changes in it), while in Jet 4, it's substantially more complex
(because conflicts are resolved at field level, rather than at
record level), and involves replica priority. There's an easily
found Knowledge Base article that explains how replica priorities
are set. Replicas with higher priorities win. The design master has
higher priority than all replicas, and any replica made direct from
the design master will have the same priority. Replicas made from a
replica of the DM will have a lower priority (and so forth).
You can also create custom conflict resolution rules that treat the
records according to your own rules.
Now, I'm assuming that this problem occurs because when I close
the unbound form I save all fields back to the table. If I'm right
so far, then I'm also assuming that the way to solve it is to only
save fields that have changed. So that's what I'm looking to do,
but I'm trying to find a neat way of doing it rather than some
horribly long winded way.
Well, never save a record that hasn't changed.
I always populate an unbound form from a recordset. I then retain
that recordset and compare the values at SAVE time to that original
recordset (make it a snapshot so it won't refresh when other users
edit the data).
It's important in replicated databases to not force saves when no
data has actually changed because, as you seem to have discovered,
this can screw up conflict resolution.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.
- References:
- Unexpected problem with synchronisation
- From: Dave G @ K2
- Re: Unexpected problem with synchronisation
- From: David W. Fenton
- Re: Unexpected problem with synchronisation
- From: Dave G @ K2
- Unexpected problem with synchronisation
- Prev by Date: Get the names of Outlook Task subfolders
- Next by Date: Re: Worked ok until put on CD
- Previous by thread: Re: Unexpected problem with synchronisation
- Next by thread: "Attaching" documents to records
- Index(es):
Relevant Pages
|
