Re: Homegrown synchronization

"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167932040.509513.160180@xxxxxxxxxxxxxxxxxxxxxxxxxxx:

Currently I'm thinking about whether to continue to just copy the
downloaded unzipped backend over the existing remote backend or to
use the downloaded backend to simply update the existing remote
backend.

The latter method helps with a potential latency issue; namely the
downloaded production backend may not contain changes made by the
remote user that were sent up to the server (presumably a short
time earlier).

OTOH, comparing the downloaded production backend with the
existing remote backend will be a slow process. While the
updates/additions can be filtered resulting in fast performance,
the deletes cannot. So for checking for deletes it is a table by
table comparison. Since I'm already doing this when the local
MyApp creates the incremental update file to send to the server, I
have an idea of how long this will take (of order 30 seconds on my
machine). Four of the 100 or so tables are responsible for half
of this time. While I suggested a method to handle these four
separately when creating the update DB from MyApp, that won't work
for updating the local backend from the downloaded server backend.
I can't see anyway around going table by table in an unfiltered
way.

Again, this points to the inherent table design problem from the
beginning; namely not having a deleteflag in the tables to
identify deletions as opposed to, what I'm currently doing, which
is to simply delete the records from the table. To others who
may be considering implementing their own synchronization, I would
recommend that you take David's advice and implement the
deleteflag method in tables. It will speed up creation of updates
and updating dramatically. I do want to point however, that
actually deleting from tables has not been a problem for us until
I wanted to implement this "homegrown synchronization".

Why not have a tombstone table in the production back end. Then
you'd just check *that* to know which records needed to be deleted.

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

Relevant Pages

  • Re: Homegrown synchronization
    ... I have a feeling that filecopying the complete zipped remote backend ... Also I'm considering having the SyncApp automatically ... issues is that if LAN users update the production backend ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... downloaded unzipped backend over the existing remote backend or to use ... the downloaded backend to simply update the existing remote backend. ... file to send to the server, I have an idea of how long this will take ... implementing their own synchronization, I would recommend that you take ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... certain tables directly in the backend that they are connected to. ... them from the server to the workstation. ... temp updateDB is set to 'Yes' that record will be deleted from the ... my app will contain a front-end table ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... server back-end you've just pushed up to the server? ... If the updating of the production backend is working correctly, ... WAN User A changes something in a table. ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... Further IT has not approved the Jet Synchronizer for use and it ... Show them the Jet Replication security update. ... concerned about mass deletions bloating the replicated backend. ... the backup/compact/update server backend app. ...
    (microsoft.public.access.replication)
Loading