Re: Sync Failed; Record is Deleted -- Append Confusion

Tech-Archive recommends: Fix windows errors by optimizing your registry

On Jul 24, 2:24 pm, "David W. Fenton" <XXXuse...@xxxxxxxxxxxxxxxxxxx>
wrote:
mikej711 <mikej...@xxxxxxxxxxx> wrote innews:cb35081a-6d25-4415-a1a9-aaf804ea6bb5@xxxxxxxxxxxxxxxxxxxxxxxxxxx
:

Yes, I know the rescued records will be given new timestamps;
that's what concerns me. The replication fields control which
records are retained and which are updated during sync. My concern
is that some rescued records may have outdated data when compared
to the set, but, because of the new timestamps they receive when
rescued, the synchronizer will treat them as new records, thus
outdated data will replace data, which by rights, is more current.

Is that concern justified?

I don't understand what you're saying.

You are going to manually identify the records in whichever replicas
happen to have data. The best thing to do would be to keep copies of
all instances of the record that is corrupt so when you delete it,
you can then create a new instance of that record and recover the
data from the backup copies you made. This will have to be done
manually.

In other words, there are two parts to the problem:

1. fix the problem that's breaking replication, from a Jet
replication standpoint.

2. recover your data and re-insert it in new records.

#1 you do by deleting the corrupted record(s) -- replication will
take care of the rest if it is truly the corruption that is blocking
the synch.

#2 you have to do yourself, and you do this by copying all the
non-replication data out of the records in all replicas before you
do #1, and then once synchronization is working again, you create
replacement records using the data you copied out of the records
before #1. This will require you to determine what data in which
fields from the collection of copies of the records happens to have
the most recent data.

Once you've got things working again and have recovered the data as
best you can, you need to figure out what caused the corruption. If
it's a memo field corruption (as is most likely from the symptoms),
it's important with replicated databases to never initiate a synch
with a replica in which a user is currently editing a memo field.
The easiest way to do this is to have your app never edit memo
fields with bound textboxes. This is easily done, by leaving the
memo field in the form's recordsource, and then edit it in an
unbound textbox (load the data into the unbound textbox in the
form's OnCurrent event, and save it out to the recordsource in the
unbound textbox's AfterUpdate event, followed immediately by a save
of the record).

If your corrupted record was not a corrupted memo field, then that
problem needs to be identified and corrected, too.

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

I found the corrupt record--the s_ColLineage reads OLE instead of long
binary--but can't delete it. Access asks if I want the deleted it and
removes it from the table, but when I reopen the table, there sits the
record. I can remove other records but not the corrupted one.

MJ
.

Relevant Pages

  • Re: Intermittant 3167 error/indexing problem
    ... I have a client with a replicated back-end database ... who sporadically suffers from data corruption. ... replication fields) before converting the new back end into a ...
    (microsoft.public.access.replication)
  • Re: Sync Failed; Record is Deleted -- Append Confusion
    ... fix the problem that's breaking replication, ... you need to figure out what caused the corruption. ... with a replica in which a user is currently editing a memo field. ... unbound textbox (load the data into the unbound textbox in the ...
    (microsoft.public.access.replication)
  • Intermittant 3167 error/indexing problem
    ... I have a client with a replicated back-end database ... who sporadically suffers from data corruption. ... I created a new back-end data file ... replication fields) before converting the new back end into a ...
    (microsoft.public.access.replication)
  • Re: [PATCH 00/16] DRBD: a block device for HA clusters
    ... have an in-kernel replicator that has much of the functionality of drbd ... md/nbd can do 1 to N replication, ... to continue rather than having the harness make a kill decision about ... corruption problem and not resume replication. ...
    (Linux-Kernel)
  • Re: Synchronisation nightmare - corruption
    ... The reason we are using replication is because the main user ... >> Conflict Viewer which stated that there were no conflict tables. ... > corruption and you can't create a replica of the corrupted MDB, ... on the network data and not under any circumstances to synchronise until we ...
    (microsoft.public.access.replication)