Re: Homegrown synchronization




I'm confused. What does Winzip have to do with downloading the
zipped production back end? Shouldn't it just be a filecopy
operation, copying the zip file sitting there on the server to the
local machine?
It is a filecopy of the zipped backend file from the server to the
remote PC followed by unzipping of that file. In my tests, when three
users simultaneously attempt to do this, I believe that normally
FileCopy would provide an error because it is already in the process of
copying the file to Remote#1 and won't allow simultaneous copying to
Remote#2. However, I never experienced any errors coming from FileCopy
but instead from WinZip. Not sure why?

If you're zipping up the current back end in order to
download it, you're simply wasting your time -- you might as well
download the unzipped file, since it's already been copied to the
local PC to be zipped up.

Or am I completely misunderstanding some aspect of what you just
said?

I don't think it is a waste of time. It is a computer on the LAN with
the server whose SyncApp zips ups the production backend file (however,
see my comments below). The remote PC has nothing to do with this as
it is too dangerous. Copying the zipped file to the remote from the
server is much faster since the zipped copy is 1/8th the size.

[]

4) If a user is connected to the server production backend and a
SyncApp tries to make a zipped copy of the production backend
files, then most of the time an error occurs with WinZip stating
that the file is in use. One time an error did not occur and the
zipping proceeded. I'm positive that the backend files were in use
based on the data that could be seen on the form, so I don't know
why zipping proceeded in that one instance. So, the bottom line
is that I'm going to leave the forced logoff functionality in the
SyncApp. Currently the forced logoff is only invoked if an
adminstrator clicks a button to create the zipped copies of the
server backend files. I have not yet included this forced logoff
functionality in the automatic creation of those zipped files.

I just think this is completely wrongheaded. You should be able to
populate an MDB for copying by appending the production back end's
data into a template. This will guarantee no conflicts or data
errors and should be relatively fast, though it adds overhead to the
process of zipping.

I guess the way to handle this is to have the 'active' SyncApp
(the one managing the server backend files), check the Jet
UserRoster for the backend files. If the SyncApp is the only one
connected, then proceed with zipping without issuing a forced
logoff message. Otherwise issue a forced logoff message with
probably a 5 minute time frame for users to get out.

I think that's wrong, because you're inconveniencing users when
there is no actual need to do so.

Point taken. I agree that, if possible, the user shouldn't be
inconvenienced. I thought forced logoff was the only way to do it
(although you did mention the 'append' method earlier). I have
switched to what you recommended. I'm going to leave the 'forced
logoff' functionality in case I ever need it, but for now the code has
been commented out. I tested the "append" method for creating a copy
of the production backend when it was in use (ie. a .ldb file was
created) several times. Seemed to work just fine, although clearly I
can't test to see if all of the data is correct (100 MB). After a copy
is created this way, then that file is the one that is zipped up and
placed in the server Outbox.

Of course this method is slower than simply doing a file copy and zip
operation; but not slower overall if you consider the time that users
must be given to logoff after receiving a forced logoff message.


Thanks.



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

.

Loading