Re: Homegrown synchronization

Some comments on WinZip:

1) Since I started using Windows API functions to wait for WinZip to
complete processing, there have been far fewer conflicts of any kind.
I actually have two backend files. The original code cycled through
the backend files and unzipped (or zipped) them. Because the
zipping/unzipping is asynchronous, the VB code just continued and this
resulted in both files being zipped/unzipped simultaneously. The
unzipping was sometimes slow and you could always see two WinZip
windows where each file was being unzipped. Occassionally the
unzipping would grind to a halt.

But now that I'm using the Windows API functions 'OpenProcess',
'GetExitCodeProcess', 'CloseHandle' to unzip one at a time and have the
code wait for the unzipping (or zipping) to complete, WinZip is working
very smoothly and quickly with no problems. Search the google msaccess
forum for the actual code to do this.

2) I have been testing what happens if three users try to check for
data updates on the server for downloading to their PCs. The 'data
update' is really the zipped up backend-files located on the server
being downloaded to the PC, then unzipped, and replacing the current
local PC backend files (NOTE: I have not yet implemented DF's
suggestion to not replace the local PC backend files but instead simply
update them with the downloaded, unzipped production backend files).
When two users do this simultaneously, I have not yet experienced any
errors. However, when three users try to do this, only two users
succeed and the third user gets a WinZip error. However, the user with
the error closes the message box, my code terminates and they can try
again. As soon as the others finish it works. So this seems
acceptable at this point in time.

3) There are command line options for WinZip that I'm now using to
overwrite existing files when WinZip is launched and also to specify
fast compression as opposed to 'normal' compression. This pretty much
removes the problem of users not completing a download of an update,
since they don't see any options to say 'No' or 'Cancel'. Winzip is
launched minimized.

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

5) Here's how I've implemented the 'semaphore' idea to determine if the
zipped files were unzipped without a problem or if the unzipping was
canceled by the user. Essentially all I've done is to create an empty
text file. When the backend file is zipped both the backend and the
empty text file are included in the zipped folder. After the folder is
unzipped, the code checks if the text file is present. If it is, the
assumption is that everything went okay.

.