Re: Homegrown synchronization

"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:

1. populate your update database to be zipped and uploaded to the
server and upload it.

2. download a copy of the server data file.

3. compare its data to the local data file and apply updates from
the server to the local database.

The only problem I can see is that you might download the next
server file before the server has applied your updates.

So, I don't understand what you mean when you say you replace the
entire back-end file -- surely you would lose the data you sent
to the server in step 1 above if you did that.

No. The synch app only creates the zipped file updates from the
production backend after an update is applied (and I'll probably
add capability to do it on a schedule as well). It then places
the zipped backend file in the Outbox folder on the server. Any
previous zip files which are in the OutBox on the server will be
replaced by the newly created zip files. These zip files are of
the production backend not any updates files sent by WAN users to
the server. Hence any updates that were previously applied to the
production backend must also be in the zipped file of that
production backend. When a WAN user starts up MyApp it looks in
this OutBox on the server for zipped files.
If it finds any, it downloads them and unzips them. These
unzipped
versions, then replace the local backend file for the WAN user.
Actually, this is what I understood you to recommend previously.
This works very similarly to my Launching program which currently
allows users to download the .mdb production backend and "replace"
the existing local PC backend (i.e. Kill and FileCopy). The zip
file download would be automated, but I'll still keep the option
to download (Kill and FileCopy) the production server backend MDB
to the local PC of the WAN user. That way if the zip code fails
for some reason (or IT somehow disables the zipper), there is an
alternative. This is what users are doing now and as far as I can
tell it has been working very well (latency issues aside).

I still don't understand how you can guarantee that you're not
losing data. The local back end would have the user's updates in it,
and when you synch, that pushes the updates into the MDB that will
zipped and uploaded to the server. All well and good. But if you
then download the server back end and copy it over top of the local
back end, you lose those edits before the new updates have been
applied to the server back end that you've just uploaded.

So, I'm having a very hard time understanding what you're doing.

In a folder on the
server, myapp code will look for a .zip file and if that file
has not already been downloaded (previous downloaded files are
stored in a table), myapp downloads the zip file and then
replaces the existing backend on the local PC with the unzipped
file. I felt it was important, however, to force my app to
wait for this asynchronous process to be completed, because
subsequently then, the app will link to the tables.

I understand that you are downloading the data and why, but I
can't figure out what you're doing with it. I'd think you'd be
keeping your local data file and also a local copy of the server
data, so that you could use the server data as comparison point
to get updates into your local data file.

Why not just replace the local data file with a fresh copy of the
production backend (via the zipping method described above). This
eliminates the need for the sync app to do anything other than
create zipped copies of the production backend. Seems simple and
pretty much guarantees that users get the current state of the
production backend at the time the zipped copy is made.

How do you not lose data? How can you guarantee that the file you
download has the updates the user last uploaded to the server?

2) When an update is found, code in the sync app will go
through each table and look for additions/edits and deletions
that need to be applied to the production back-end file.
Whether the record is an add/edit or deletion depends on the
value of the UpdateorDeleteFlag mentioned earlier.

How do you make certain they get applied in order? That is what
if you are updating from a remote user who deleted a record on
1/1 and then you get an update from another user who updated that
same record on 12/31? And what if that were an update, instead?
Do you just ignore the 12/31 changes? What if they should be
merged, instead?

Well, that's a good question. I actually posted in another forum
if there was some way to get Dir to get the files in folder in a
certain order.

There isn't. Dir() will return files in the directory order, which
is not necessarily in the order of creation. You'll need to sort the
list. Maybe the file system object has better tools for returning
sorted file listings.

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.

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?

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

Relevant Pages

  • 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, ...
    (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: Trend updates if server is unavailable
    ... the Security Server checks the ... If you define a source other than the Trend Micro ActiveUpdate Server ... for receiving updates, then all computers receiving updates must have access ... Use the ActiveUpdate server for the component download source. ...
    (microsoft.public.windows.server.sbs)