Re: Homegrown synchronization

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

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.

[]

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?

Now I want to concentrate on David's concern about what happens if
more than one user tries to synchronize the production backend
(which he is recommending that I avoid by using an intermediary
app).

No, the intermediary "app" (actually, just an empty MDB) serves only
one purpose: to allow you to track who is running the synch app and
prevent more than one user from doing it at once.

The way
things are now, this can happen. It's important to note that I
can't have a software program (like Jet synchronizer) running on
the server to take care of all the production backend
synchronization (that's one of the main points of creating my own
synchronization scheme).

So I'll be studying his suggestions on an intermediary app and the
.ldb file.

The whole point of the intermediary MDB is that it allows you to
create an LDB file that tells you only who has the synch app
running, and then to prevent no synchs except from the first of the
users to have opened the synch app.

I've explained this multiple times, and don't know what I'm doing
wrong in my explanation that is making what I say opaque to you.

The main reason for the intermediary app is because you can't use
the UserRoster for the back end file, because there's no way to
distinguish a synch app logon from a garden-variety editing logon.
That's why you need an LDB file somewhere that allows you to get a
UserRoster of synch app users. One way would be to share the synch
app, but, as you pointed out, that's dangerous, in that it can lead
to corruption (but it would be very simple). So, the alternative is
to use an empty MDB sitting on the server. When the synch app opens,
it does this:

Dim db As DAO.Database

Set db = DBEngine.OpenDatabase([intermediary MDB])


Then when your synch app shuts down it does this:

db.Close
Set db = Nothing

Now, what that does is tell you who is running the synch app. In
order to control the synching so that only one user is synching at a
time, you have two choices:

1. have only the first user do the synching, ever, and hope that you
never have a case where the second user stays logged on forever
after the first user logs out, OR

2. have the synch timer check if all the users who were logged on
when the synch app was launched have logged out.

What you'd do is this:

1. when the synch app starts up, it opens its db pointer (as above),
which creates the LDB.

2. get the UserRoster for the intermediary app. Save the list to a
global variable.

3. if you have a timer that checks the dropbox and synchs every 10
minutes, make that code run for all users, and each time it runs,
check if all the users who were in the user list retrieved in #2
have logged off.

4. If they haven't logged off, skip the synch.

5. If they are all logged out (even if there are others logged in
after you), take over as the synch app.

The reason for this is that this means that as long as the synch app
is running on one PC, the scheduled synchs will occur, but will
always be limited to only one PC.

There's actually one other alternative, and that's to use a Jet
user-level security logon for the synch app that is specific to the
synch app. That way you wouldn't need the intermediary app, because
the synch app would show up as a different username.

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

Relevant Pages

  • 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: 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)
  • Re: SUS
    ... > I have setup a SUS Server on win2k. ... 0-2.reg will not configure your machine to automatically download updates from ... critical updates or service packs that your machine needs. ... It will also ask you if you want to install them, ...
    (microsoft.public.windows.server.general)
  • Re: FYI for eTrust AV 7.x Users
    ... When I just had my little incident with the redistribution settings on the SBS, my clients were logging successful checks for updates, and the logs indicated that no updates were found. ... That turned out to be because I had not gone back and checked the redistribution server box for 8.x after reinstalling the redistribution server. ... installed the new remote install utility which works the same as v7 did - just edited the .ICF file the way I wanted it and ran the client upgrades from the server. ... I can't remember if it's a separate install, or if you have to click a box when you do the Agent install, but redistribution server is not installed by default. ...
    (microsoft.public.windows.server.sbs)
Quantcast