Re: Homegrown synchronization


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

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.

On a schedule, which means there's a time period when the server
back end doesn't actually have the updates, and if the back end is
downloaded during that time period and overwrites the user's back
end, the most recent updates would be missing (until the next
download, presuming it doesn't happen until after the scheduled
server synch happens).

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.

Well, that's what I assumed, that at some point the server back end
would be downloaded to get updates back from the server. The
question was what was done with that back end, whether it was copied
over top of the local back end, or used to update the local back
end, instead.

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??

We're talking past each other.

I have no problems with what you've proposed for getting the user
updates to the server. None.

The issue was that I understood you to have said that you'd download
the server back end and *replace* the user back end in order to get
the updates back from the server. I'm pointing out that this is
problematic (seems to me) and that there are other ways of getting
the updates to the user.

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.

This part I've fully understood all along.

Are you saying to reverse it.

No. You're thinking I'm saying something completely the opposite of
what I am. I'm not talking about user->server but server->user.

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.

No, that's not at all what I was proposing, at any point.

But it would still need to have the synch app running on the server
end of things to get the updates from the uploaded file into the
production back end.

Is this what your suggesting or am I totally lost.

This is not what I'm suggesting.

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.

I'm not proposing that you change that.

The code has all along been written to
create a LOCAL update file to be sent to the server.

I'm not proposing a change to that.

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???

I was not proposing a two-way update. I was proposing only that the
user back end be updated from the downloaded copy of the server back
end, rather than replacing it entirely with the downloaded server
back end (as I understood you to be proposing).

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!

I don't know where what I wrote lead you to believe I was proposing
what you've outlined above. I was responding to *one* small point in
your process, how you got updates from the server back to the user.

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

Whew! I guess you can tell I was a little panicky there, thinking that
maybe I had gotten this all wrong and all those days of long hours were
down the drain. Thanks for remaining calm in responding.

Okay. So we're fine with the method of creating updates from a remote
user and sending them off to the server. The SyncApp then applies
those updates to the production backend. Since the 'managing' SyncApp
is on a user's machine that is part of a LAN connection with the
production backend server, this has a very high probability of success
(as opposed to doing it over a WAN connection).

So the issue now is how do we update the local backend copy for the
remote users. I've currently only been creating a zipped copy of the
production backend after an update is applied to the production
backend. But your right, there could be problems with this
particularly if I schedule generation of the zip file.

I think the reason I need to have the whole copy of the server
production backend is primarily because I don't know what LAN users did
with regards to updating the backend.

So we agree that we need to copy a zipped copy of the production
backend to the remote user. Now the only question is what do we do
with that copy. I'm proposing copy over the existing local backend
file and your proposing to use the downloaded copy to update the local
copy.

Okay. Let me think about this a bit. It does have the major advantage
of not making A think that they have to enter the data again (the
original data would get back to A eventually probably an update or two
later). But if there were a lot of updates made by A that day, they
might get pretty angry (even though those updates would probably
eventually get back to them). If I can code around that possibility,
why not.

.

Relevant Pages

  • Re: Homegrown synchronization
    ... How do you trigger the application of the updates to the server ... The only problem I can see is that you might download the next ... production backend after an update is applied (and I'll probably ...
    (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)
  • Re: Strange Server Behaviour
    ... Thanks for updates. ... I am Charles the backup of Brandy, as the Brandy is currently sick at home. ... Microsoft CSS Online Newsgroup Support ... | Subject: Re: Strange Server Behaviour ...
    (microsoft.public.windows.server.sbs)
  • Re: WSUS Client not yet reported
    ... The client still fails to report. ... Check your server status ... Suggestion 2: Check the IIS settings: ... any updates in your thread. ...
    (microsoft.public.windows.server.sbs)