Re: Homegrown synchronization

Just as I sent off the last post, a thought occurred to me.

I have a feeling that filecopying the complete zipped remote backend
file to the server is going to take at least several minutes. Couldn't
I just handle this step using a batch file. It should work fine when
someone invokes this 'send an update to the server' from the menubar
item. But what if someone is shutting down MyApp. If the code
determines that MyApp should send an update, I'm not sure what happens
to the batch file that is filecopying the zipped complete remote
backend to the server Inbox when MyApp actually shuts down. I guess
this should work okay since it is a separate asynchronous process, but
suggestions and comments from the more experienced are greatly
appreciated.

It would seem then that the only potential problem would be that a user
tries to shutdown their PC while the batch file is still running.

Thanks.

rdemyan wrote:
David W. Fenton wrote:
"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1168317601.805220.16270@xxxxxxxxxxxxxxxxxxxxxxxxxxx:

Right now I'm only creating these zipped copies after an update
from a remote PC is processed by the SyncApp. Ten minutes sounds
reasonable. Also I'm considering having the SyncApp automatically
create a zipped copy of the 'Append' copy of the production
backend file if a zipped copy has not been created in the last
couple of days (maybe as short as one day). Again one of the
issues is that if LAN users update the production backend
directly, the SyncApp doesn't know about this and waiting for
updates from WAN users may lead to unacceptable latency.

Can't you check the data? If you find one record in one table
updated since the last zip file was created, you create a new one.

Yeah, that's probably the way to do it. Besides there is a button on
the SyncApp to create a new zipped copy of the production backend which
administrators can always invoke if there is some problem.

I'm currently at a different site that also uses MyApp. I've been
playing around with this whole sync scheme. We are supposedly on a LAN
here, but the time for some of these tasks is very long.

Example: To have the SyncApp create a 'hot backup' (using the Append
method) of the production backend file (100+ tables totalling 100 MB)
and zip up that 'hot backup' takes about 60 to 90 seconds IF the
production backend is located on the user's PC hard drive (this is a
hypothetical case designed to estimate what the minimum time is). When
the production backend is on the server, that process takes 25+ minutes
[SyncApp is on the PC which is supposedly connected to the server via a
LAN]. I'm beginning to wonder if we truly have a LAN connection.

This time doesn't even include actually updating the production backend
with an update file sent in by a remote user. I need to get a feel for
how long that takes. Fortunately, all of this processing is
essentially transparent to the user since it runs from the SyncApp and
doesn't affect their ability to work with MyApp.

However, it looks like 10 minutes for the SyncApp timer is going to be
too short. I assume that I don't want to have the timer so short that
it fires while the processing from the previous timed event is still
running. So I guess I'm looking at 30 to 60 minutes. Also, I'm
planning to store the timer value in a table so that administrators can
change it for their actual WAN/LAN setup.

I still haven't made up my mind on whether to send an incremental
update to the server InBox or the complete, zipped up, remote backend
file. I need to get a feel for the relative amount of time it takes to
do this. If I send the complete zipped up backend file, I'll probably
just close all forms and recordsets and create a zipped copy of the
remote backend file to send; as opposed to using the 'hot backup'
method that David suggested for use to create copies while users are
using the backend file. It's a time issue. I'm trying to keep the
experience of sending an update to the server in the 1 minute or so
range. Not including the 'hot backup' step should help. Of course,
then the time to actually filecopy the zipped backend will be longer
than the time to filecopy an incremental update. The typical ratio in
file size is about 50 to 1 assuming just a few records were changed in
the backend and only those records are sent via the incremental update.

Fortunately, everything regarding WinZip is working just fine at the
site.

.

Loading