Re: Homegrown synchronization

"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167521380.825314.321980@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

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

[]

Now, that's subject to the remote possibility of corruption, as
you could be zipping up a file that's in an incomplete state (say
some data pages have been written from a transaction but not all
at the moment that your zip library compresses the file sectors),
but in all the years I've copied open MDB files, I've never seen
a single corruption. Of course, you'd be doing it systematically,
so perhaps it *would* be better to have an intermediary database
that is populated on a schedule (once every 10 minutes?) with
data from the production database. When it's created, then you'd
zip it up, and whatever the last zip copy is is what the remote
users would download. That seems like a better idea to me.

Currently, my launcher just copies the production backends as is.
Are you suggesting to maybe have the sync app zip up the
production backends. Change my launcher to download .zip backends
instead of .mdb backends. Interesting. I'm a little worried that
if a WAN user tries to zip the production backend, that it could
cause corruption (unreliable connection).

I would never do this, because for a WAN user to zip up the
production back end, it has to be copied across the WAN and zipped
in the RAM of the WAN user's PC -- this makes no sense! It is a
waste of time, as in order to zip it up, the original file has to be
copied across the wire.

What you need is to have the synch app zip up the production
database at intervals (or a copy of it -- doesn't matter for the WAN
architecture, though it may matter for potential corruption), and
then the WAN users won't be doing any across-the-wire zipping of
anything.

But the sync app is on the LAN so it could
create zip files at regular intervals. The launcher for WAN users
would then download the zip files and unzip them. This could work
nicely because I've seen about a factor of 10 reduction for a
zipped backend.

I should read ahead before replying!

If I can do this, would I just write over any existing .zip
files that are on the server folder where my launcher looks.

You'd only need one zip file for the production database, and it
would always be the latest one created by your synch app.

Example.
Sync app creates a zip file of the production backend after it
applies an update. Now the sync app doesn't really know what any
LAN users connected to the production backend are doing. It seems
to me it can only handle this based on a schedule. So maybe have
the sync app create zipped copies of the production backend at
regular intervals (but wouldn't this fail just like VBA FileCopy
does if a user is actively using the data). But in order to
prevent hundreds of copies from taking up space, just overwrite
and maybe occassionally create a backup stored somewhere else.

I would not link the production database zip files to an incoming
synch -- I'd do it on a schedule.

As to failure, no, file copies don't fail when the MDB is in use,
but the result could be internally corrupt (though I've never even
once encounterd that -- it's theoretically possible).

But as usual there may be an issue with IT. We're still on
Windows 2000 (believe it or not, XP is not yet "certified" for
use), so no native zipper that I'm aware of. I never use a
zipping program on site, so I called a colleague and he said that
he uses WinZip on his workstation. I pointed out that he couldn't
have downloaded it, so IT must have installed it. But he wasn't
sure if it was a registered copy. Given the way IT is, I would
think it would have to be registered, but I'm not sure yet
(they're not just bastards, they're cheap bastards). Anyway, I've
discovered that code to zip up files only works correctly with
registered WinZip programs.

I gave you a link for this so you won't have to use an installed
program. It uses a free zlib.dll that you can distribute with your
apps. I didn't examine the code to see if the dll needs to be
registered. If it does, then create a reference to it, stored in the
same folder as the MDB app that is making use of it, and it will
always be valid, even if not registered.

5) My plan was to launch the synch app when my main app
launches; but only for users who are given permission to do so
(this would be set in my main app when a user is setup to use
the main app). The reason for this is I want to restrict who
can launch a synch app to only those individuals who are
connected to the LAN where the shared production backend is.
Sure I could not distribute the Synch app to the WAN users, but
my plan seems safer since users could still get a copy off the
server. This way I don't need to add additional instructions
for new users (the more instructions, the more confusion, the
more calls......).

OK, well, I'm confused again. Why would you want multiple LAN
users synching? Don't you want your LAN users using the
productiong database?


But the key point is: you don't want multiple users running a
synch at once on the production database, because that will
increase the chances of update collisions. You'll want one synch
app running on your LAN, taking care of scanning the incoming
dropbox for update databases and then applying those updates to
the production database.

There are two goals I see there:

1. you want only one copy of the synch app, BUT

2. you don't want to lose the synching when some user happens to
shut down her workstation (and close the single running synch
app).

That is accomplished by one of the two methods I described,
either sharing the synch app and using its LDB file to figure out
who got to it first, or using the intermediary MDB I suggested
for the sole purpose of tracking who is running the synch
program. The first user in the LDB gets the privilege of running
the synchs. Users who start up the synch program when there's
already someone in the LDB won't get to synch. But if you have,
say, a 10-minute timer-based synch interval, you'd want to have
it check the LDB file each 10-minute period to see if all the
users that were logged on when the synch app was launched have
now logged out. That will insure that when the master
synchronizer closes the synch app, the synch app of the next user
to have logged on will take over as master synchronizer.

So the sync app then is on the server and is launched by each LAN
user when they launch my app. Bear in mind, I've never launched
"front ends" from the server as this is usually considered bad
practice (however, I think a good idea for what I'm trying to do).
I'm not questioning this, I'm just saying I don't have any
experience with an app launched from the server.

I agree that this is a potential problem. That's why I introduced
the concept of the intermediary front end. You wouldn't even need to
*use* the intermediary front end -- it could just be an empty MDB
file, and if you set a DAO database variable that pointed to it, the
LDB file would be created.

Couldn't I also create a Logon Table that monitors who's in. I
guess the only problem with that is if there is a crash, then
user's won't be logged out in the table.

Why reinvent yet *another* wheel? The LDB will function just fine,
and using an MDB dedicated to the purpose of sitting there waiting
to be referenced in a DAO variable just so you can monitor the
contents of its LDB file should work just fine.

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