Re: Homegrown synchronization


David W. Fenton wrote:
"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167757655.154686.125340@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

David W. Fenton wrote:
"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167694158.878560.213810@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

David W. Fenton wrote:
"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167608261.069673.213770@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

[]

2) Updates to the remote local PC are now done by simply
replacing the entire backend file with an update from the
server.

I don't understand this. How do you not lose updates this way?
How do you trigger the application of the updates to the
server back-end you've just pushed up to the server? I would
do it this way:

If the updating of the production backend is working correctly,
then I don't think it is so much a question of losing data.
Example: WAN User A changes something in a table. When they
shutdown MyApp, the CreateExportUpdate code is invoked. It creates
an UpdateDB and copies it to the server Inbox and then moves the
local UpdateDB (just copied to the server) to the Archive Outbox
on WAN User A's harddrive. Now User A has shutdown.

SyncApp for a LAN User F finds the update and applies it to the
production backend. It then creates a zip file of the production
backend (okay, I may change the timing on this method, but that's
how it works now). That new zip file is put in the server OUTBOX.
When WAN User A logs in again, MyApp finds the new zip file in
the server OUTBOX, downloads it, kills the local backend and
unzips the new backend.

Now if WAN User B has also sent an update that got applied to
production backend prior to WAN User A logging back in again, then
a new zip file was created of the production backend that contains
both WAN User A and WAN User B's updates. When A logs in again,
he gets a fresh backend (via zipped file) containing both updates.

What if A logs off and, realizing she has forgotten something, logs
on again, before the server has had time to apply the changes that
were just uploaded? What if, for some reason, there's no synch app
running on the server's LAN (everyone shut off their computers)?

I just don't see why you don't just apply the same code you're using
and download the server back end and then update the local file
accordingly. Or, overwrite the data file and run the file that was
just uploaded against the newly downloaded file. If it's already got
the updates, no problem. If it doesn't, it will now have them.


Whoa! I'm totally confused. Let's make sure we are on the same page.
WAN User A makes a change to table on his local copy of the backend
file. When MyApp closes it creates a small update .mdb that includes
only the changes made by WAN User A during that session to A's local
backend file. That update .mdb is sent to the server location where
the production backend is. The SyncApp that is handling the production
backend, will apply the update sent by WAN User A based on the form
timer.

So now your saying to also download the production backend from the
server or in lieu of what I just stated in the previous paragraph.

I think you can argue that this can be a timing issue. But I
would counter that as long as WAN User A's update got applied
(gets applied) to the production backend, he will eventually have
it sent back to him in the zip file.

But with deletes, the order really is important!

I would also bet that this would work the next time a
user logs on in 99+% of the cases, if I get the timing issues
correct for synchronizing the server and assuming a user doesn't
shutdown and then immediately get back in.

Given that that 1% of the time is foreseeable, I'd never put in
production a system that doesn't account for that 1% and prevent it
from happening, especially when it's relatively trivial for you to
port code into the user app that you're already using elsewhere.

Now, if WAN User A's update doesn't get applied, then no one gets
it including User A. In your scenario, A would still have it.
Not sure if this is better. If the update fails and no one has
it, except A, then it could be a very long time before anyone
notices it. Why, because my WAN users kind of operate as islands.
A knows A's data, and C (over at a different WAN site) knows C's
data but doesn't know A's too well (and vice-versa) but still
wants a look at A's data for comparison purposes. But usually
only A will notice if there is a problem (at least in a reasonable
amount of time). With the incremental update method, A goes
merrily along thinking everything is fine until SOMEONE else
points out the problem. But it is A who is in the best position
to notice it.

Will A be happy to lose all her most recent data? I just don't see
how you could take that risk. Either the data matters or it doesn't.
You're depending on timing to go right when you have no control
whatsoever over the timing of the events. I think that's completely
unwise.

The alternative, which is to apply incremental updates, could mean
that updates from other user's (like WAN User B) are not applied
to WAN User A's local backend in a timely fashion (which is I
think what you are getting at). Why? Because right now MyApp only
checks for updates (regardless of whether they are incremental
updates or zipped copies of the production backend) at startup.
There's no checking going on during a user's session. If
necessary, I can maybe add that later. Right now I want to get
this working smoothly.

I still don't get it. The question is: how do you get the updates
from the server to the user. You're replacing the user's data file,
if I'm understanding correctly, even though you can't know for
certain that the user's most recent updates have been incorporated
into that data file on the server.

I'm saying:

Download the server data file.

Apply the last set of updates to it, and *then* replace the existing
data file.

THe existing local file? What about needing to get the just updated
server file (on WAN User A's PC) backup to the server so that other
users can get A's modifications??

That way you know for certain that you've got both the
latest server data and all the changes that were last sent up to the
server. And it is completely non-dependent on the timing of the
updates on the server.

When WAN User A updates a table, it is first updated in the local
backend file. Then when MyApp closes, it finds the updates in the
local backend file and creates an update .mdb to send off to the server
so that the server file can be updated. The update .mdb only contains
the records that were added, edited and deleted during the session,
nothing else. So my method has been to upload the usually small update
file to the server and update the production backend file in place on
the server.

Are you saying to reverse it. In other words, WAN user A just updated
their local copy of the backend file. So now what we need is to get
any other updates to WAN user A which presumably are in the production
backend. So, instead of creating an update file to send to the server,
download the production backend to the local WAN PC and look for
differences between the production backend and the local copy (which
was just updated by User A)??? And presumably this would be a cross
updating. So A's local copy updates downloaded production backend and
downloaded production backend updates A's copy??? Then the just
updated downloaded production backend needs to be sent back to the
server so that other's can get the updates. If this is the scenario,
then I'm not clear on what the sync app does?? All updates would be
applied locally with the production backend just being passed around.

Is this what your suggesting or am I totally lost. I think is the
first time I've heard about this. In virtually all of the posts (over
50), my strategy all along has been to update the server backend pretty
much in place on the server. The code has all along been written to
create a LOCAL update file to be sent to the server. Not to download
the server file, perform a cross update (I guess that's what your
suggesting) and then send the downloaded server file back up to the
server???

This is totally different than what I've been planning? It has its
intriguing points but isn't this a total paradigm shift??

I look forward to your reply as you've totally lost me!



My comments above are tentative. I don't disagree with you; I'm
just relaying my thought process. I may have missed something or
be looking at it wrongly. This has been a long and arduous
process and I'm starting to go bonkers :)

You've written the code already. Why can't you just incorporate it
into the user app?

[]

The sync app loops through files in the INBOX folder on the
server to find all of the update files sent by WAN users. Each
file does include a date and time, so maybe I could somehow use
that.

But that's only the date and time of the *file*, not the data and
time of the updates included within it. If somebody doesn't synch
until a couple of days after they do updates, the file could be
dated several days after the actual data, and that means you
can't process them in order of file date -- you'd want to process
them in the order that the changes were made.

No, actually each update file has the user's logon ID and the date
which the update file was created in the file name. So I do know
when the update file was created and by whom.

But that doesn't tell you the date of the *data* changes in it. Now,
if you can count on the upload completing each time the user exits
the app, perhaps that's OK. But I'm not sure that's safe.

After
an update file is applied to the production backend, a record
is written to a table so that that update is not applied again
by the sync app (as part of the Form Timer code). I may want
to allow admin people, however, to specify that the sync app
should try again on a file that the administrator would select.
This functionality has not been added.

Why not just move the file to an archive once the update has been
applied to the server?

Yeah, that's a possiblility.

Seems to me there's nothing to lose by doing so.

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

.

Relevant Pages

  • 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
    ... 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)
  • Re: Homegrown synchronization
    ... the entire backend file with an update from the server. ... The synch app only creates the zipped file updates from the ... These zip files are of the production backend ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... How do you trigger the application of the updates to ... the 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
    ... How do you trigger the application of the updates to the server ... If the updating of the production backend is working correctly, ... to the server) to the Archive Outbox on WAN User A's harddrive. ...
    (microsoft.public.access.replication)
Quantcast