Re: Homegrown synchronization

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

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?

Why would Winzip be involved at all? You're copying a file, not
opening it.

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.

Well, I am glad that's the case. I couldn't see any way that Winzip
would be giving an error if you weren't executing Winzip from the
remote PC and zipping across the WAN -- this, as you obviously
agree, would be a mistake, and that was the only explanation I could
come up with for a Winzip error.

I'm stumped as to what Winzip has to do with it.

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.

It has to be correct, because Jet is reading the data and doing the
append. It knows about its own record locking so it won't violate
any of them and copy incomplete records or edits in process.

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.

How often are you doing it? I'd do it after every actual update from
the synch app, which I'd probably have running ever 10 minutes.

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