Re: Homegrown synchronization

Tech-Archive recommends: Fix windows errors by optimizing your registry

Here's where I am now at:

1) I have implemented the Jet UserRoster code to check how many
"adminuser" UserID's are logged on. If greater than 1, that means that
more than one synchronizer has a connection to the production backend
file. I've added a label to the sync app form, which tells me which
sync app is the currently 'active' one for the purposes of 'managing'
the production backend. That all seems to be working okay.

BUT..... This has spawned some issues with using VBA FileCopy and with
using WinZip. As I have mentioned a number of times, the launching
application for MyApp allows WAN users to download a copy of the
production backend to their machines. The code uses VBA FileCopy.
I've known for some time that if another user has a connection
established with the production backend on the server, FileCopy
generates a 'Permissions Error' and fails. Now, with synchronizers
from any number of users on the LAN with the production backend
establishing 'persistent connections', this becomes a much bigger
issue.

So you're saying, well just download a copy of the production backend
and not the actual backend. It's probably dangerous to FileCopy the
actual production backends. Okay, just one more thing to do. It
probably would be better to only move zipped files back and forth, but
I wanted to leave this functionality available in case IT ever gets rid
of WinZip (just like they got rid of Windows Scheduler and remember
we're still on Windows 2000, so no native zipper that I am aware of).
Maybe I'll add code to check for the existence of Winzip and if found
always look to transfer a zipped file of the production backend from
the server to the WAN user. If not, the switch to FileCopy (or
possibly file scripting CopyFile).


But here is a bigger issue. I'm currently using WinZip to zip up the
production backend after an update has been applied by a sync app.
I'll probably extend this to included scheduled creation of a zip file
for the production backend. This is a convenient method for providing
an updated production backend file to the WAN users. I don't have to
do any fancy coding to create an 'incremental update' to be applied to
WAN user's local copies of the backend. Instead the entire local
backend is replaced by the unzipped production backend.

But now with the persistent connections from the synchronizer, WinZip
is also having issues. It proceeds to make the zip file, but gives a
warning that the file may be corrupt. When the detailed warning is
viewed, it actually says that the file is 'in use'. So the persistent
connection must be working.

If I go back to the 'incremental update' to be 'pulled' by MyApp for
WAN users, this problem goes away, but I'm really liking the idea of
zipping up the entire production backend (or possibly a copy thereof)
for WAN users. I also read somewhere, that the zipping and unzipping
process also does some error checking to check the integrity of the
file. This would be good for getting updates to the WAN users. When
the file is unzipped if there's a problem, then WinZip will probably
alert the user, which is a good thing.

I could go back to the 'incremental update' to be sent to the WAN
users, but I was hoping to just have myApp for WAN users simply copy
the zipped entire backend file. That process doesn't have a problem,
because, the Sync Apps do not have persistent connections to the zipped
file. No, it's the creation of the zipped file from the production
backend with Sync Apps having persistent connections that is the
problem.

2) I think I'm also going to add code to the Sync App that alert the
user when their Sync App is the only one available to manage the
production backend. So if the user closes MyApp, instead of just
closing the associated Sync App on the user's machine, I'm going to
check the Jet UserRoster to see if that is the only Sync App available
to manage the production backend. If True, then alert the user and
strongly recommend leaving the Sync App open.

Sound reasonable.

3) With regards to LAN users that are connected to the production
backend when the Sync App needs to apply an update or create a zipped
file of the backend, I'm still leaning towards booting everybody out or
making this whole synchronization process a scheduled late at night
event. I know David finds this draconian, and I don't disagree, it's
just that it would simplify things and remove a potential avenue for
corruption.







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

With regards to how to handle the synchronization of the
production backend on the server, I see the following problems
(the sync app only handles the production backend on the server
not any local backends for WAN users):

1) How to make sure that only one sync app at a time tries to
apply an update found in the "UpdateInBox"

I've explained this. You need to know who has the synch app opened.
There are two ways to do this:

Sorry. I double posted because I thought I had lost the post
immediately prior to this one. It didn't showup after ten minutes so I
reposted but didn't have a copy of what I posted before. So the ideas
are the same just different wording. So, I'll only respond to this
post.


1. the intermediary app to maintain a separate UserRoster (i.e., LDB
file) of users running the synch app, OR

2. running the synch app under a different Access username, so that
you can tell from the back end's UserRoster who is running the synch
app.

2) How to handle the sync app applying updates to the production
backend when other LAN users are connected to it.

That's simple enough. You wrap your updates in a transaction and
have your updates execute with dbFailOnError. If it fails, you roll
it back and wait to apply it later. You might retry immediately, or
wait 5/10/15 seconds, or reschedule it in 10 minutes, or whatever.

I believe David had suggested earlier that I need to determine who
opened the synch app (or alternatively the intermediate app) first

Not so much who opened it first, but if anyone else already has it
open when you start the synch app. Any user who opens it at a time
when nobody but themselves is listed in the UserRoster would become
the synchronizer.

For users who open it after someone else is already doing the
synching, their synch app would wait until all the users who were
logged on when they opened it have logged out, and then they would
become the synchronizer.

Another option is to launch the synchs with a different logon
username (this is perfectly doable in DAO by opening a separate
workspace, something you would likely be doing anyway if you're
using transactions for your updates) and if at synch time nobody is
logged on as that user, have the app take over and synch.

Actually, that makes a great deal of sense. At logon, the synch app
would check the UserRoster for the intermediary app (or for the back
end) and if the synchronize username is logged on, do nothing. Every
time the synch timer runs, check again, and if the synchronizer
username is no longer logged on, create the new workspace with the
synchronizer username and open a connection to the back end. Then
take over as the synchronizing machine.

Yes, this is more elegant, I think.

Doh! Now that I realize I don't have to get the first user, this is the
way to do it. In fact, it's already done!! All of my apps are
workgroup secured including the SyncApp. I don't like to store a
user's password anywhere, so a long time ago, I created an
administrative UserID called 'adminuser' and assigned a password. So
when MyApp opens the SyncApp via a Shell command, I pass in the
'adminuser' User ID and the pwd. I don't worry about someone using
this user ID and if they can get the PWD to open MyApp. I hard coded
in MyApp that if 'adminuser' logs on, shut the app down.

Yes, yes, this is much more elegant. So when each SyncApp, located on
each LAN user's machine, it checks the JetUserRoster on the backend
file. If one of those users is already 'adminuser', then the syncapp
does nothing, When the timer runs, have it check again. If there is
no 'adminuser' logged in, then run the code to link to the production
backend file (I know I repeated what you said, but I'm starting to
understand at least this part).


I'll stop here and proceed. I know I'm moving one baby step at a time,
but I think the fact that I now understand that it doesn't have to be
the FIRST user and can use 'adminuser' to determine whose already the
'syncher', I can move forward. I'm sure I'll still have some issues,
but now I can start moving forward.

.

Relevant Pages

  • Re: Homegrown synchronization
    ... I thought the synch app was designed to do the scheduled synchs, ... The Sync app is the app that works on syncing the production backend on ... is handling the production database. ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... implemented the "intermediary app" that David has recommended, ... production backend file on the server. ... explained below under the 'Synchronizer' discussion. ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... (the sync app only handles the production backend on the server ... How to make sure that only one sync app at a time tries to ... You need to know who has the synch app opened. ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... I have implemented the Jet UserRoster code to check how many ... username, then you just close the connection, then open it and check ... production backend to their machines. ... the user when their Sync App is the only one available to manage ...
    (microsoft.public.access.replication)
  • Re: Homegrown synchronization
    ... username, then you just close the connection, then open it and check ... Why are you using Winzip? ... production backend to their machines. ... the user when their Sync App is the only one available to manage ...
    (microsoft.public.access.replication)