On Dec 24, 12:47 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:

Hi David:

Nice to see you are still maintaining this group.  It's been a while
since I checked in and I noticed a lot of spam.  Before I get to the
topic at hand, I wanted to mention that one thing that really helps
the Homegrown Synchronization method is the use of a zipping program
to move files from the server to the local PC and vice versa.  This
reduces file size by almost a factor of ten and I haven't had any
complaints from any users regarding the time it takes to "download"
new complete back-end files from the server.  Even at the location
1200 miles away, it doesn't take any longer than about 2 to 3 minutes
to download the BE files (almost 20 MB in total).

I don't see how just recording the login and logout tells me if the
backend files have been modified.  Your second suggestion won't work
for me either, because MyApp was not designed to handle this method.
We discussed your suggestion almost a year ago and it would have just
involved too many code changes (Virtually all of my forms are unbound
and I use code to handle table changes).  This was the reason I
originally decided to create a temporary copy of the BE files and just
create one code module that upon closing of MyApp would compare the
current local BE files with the temporary BE files (created at
startup) to see if their are changes. If changes, then a small zipped
update file is created and copied over to the Server Inbox.   If I had
designed MyApp at the beginning to use your suggestion it would have
been better, because determining if updates were made would be easy
and fast. But retrofitting it in after 18 months of work was just too
difficult.  Also, now that the client has finally updated all machines
and gone to Windows XP professional, speed is hardly an issue when
creating the temp local copies and checking for changes upon closing
MyApp.  The SyncApp can still be slow because it is a local copy (IT
won't allow any apps to run continuously on the server) and depending
upon the distance from the server.  But it doesn't really matter
because no one uses the SyncApp for accomplishing work.  It
essentially runs in the background on their local PC.

It just occurred to me that I could treat the server back-end files
like the local PC back-end files when it comes to checking for
changes.  So when a user logs in and connects to the server BEs, a
local copy of these BEs is made.  Then when the user logs out of the
server BEs, the code checks for differences between the server BEs and
the local temporary copies of these BEs (this is exactly what is done
when a user connects to LOCAL copies of the BEs). If a difference,
create an updateDB and put it in the Server Inbox.  The SyncApp will
find the updateDB and apply it just like always.  It seems that the
code changes in this case would be minimal since the hidden startup
form of MyApp has text boxes that contain the Local PC folder, Server
folder and if the user is connected to the server BEs or the local
BEs.

Two issues come immediately to mind:

1) If someone else is logged into the server BEs, then VB code won't
be able to create a temporary copy (the copy is only for the
session).  I believe, however, that Window API copy command will.  But
this no doubt will increase the chances of corruption.
2) Higher likelihood of corruption when creating the temporary BEs on
the local PC from the server BEs.

1) seems more likely to be the problem.  However, currently only one
person besides me has been connecting to the server and that's only
because he wasn't setup correctly to use his local copy of MyApp.  He
was actually logging on to the server copy of MyApp (which, of course,
Microsoft discourages).  Everyone prefers the speed afforded by
handling all connections on the local PC.

Since Homegrown Sync is working well, maybe I shouldn't allow users to
connect to the server unless they are administrators of MyApp.  After
all, any change they make on the local copy creates an update file
that is sent to the server inbox.  The update file name includes their
User ID, so I can see who is actually making changes to data just by
looking at the files in the server folder.  This allows me to
administer the program better.  If a user consistently changes data
because they don't understand how the app works, I can demote them to
a User Group that does not have permissions to send updates to the
server.  So they can change their local copy of the data to their
heart's content and it will never affect the server (except of course
if they actually use Windows Explorer to copy over the server BEs; no
way to stop that except switch to SQL Server, Oracle, etc).  Then
periodically when they log in, updated BEs (created as a result of
someone else updating data) is sent to them anyway; this is at least a
once a month event.

So far this hasn't been an issue, because frankly, I'm the only one
who knowingly connects to the server BE files.  On the MyApp Logon
form, I included code that notifies a user if they have selected to
connect to the server BE files.  The message informs them that the
connection speed could be slow and gives them the chance to change
this selection so they can go on logging into their local copy of the
BE files.

Now that I've completed this message, I'm leaning towards not allowing
certain user groups to connect to the server BE files.  At this point,
nobody really wants to anyway, because they prefer the speed afforded
by connecting to local copies of the BE files.  Just an aside: this
speed is an important issue because MyApp is calculational intensive.
Hardly any forms just display data directly from a single table.
Virtually every form pulls data from multiple tables and many forms
have to perform calculations/comparisons of data before it is
displayed.  Also,  most forms deal with tens to hundreds of thousands
of rows of data upon which calculations or comparisons are done prior
to display (the displayed amount of information is generally much
smaller).  To keep users continuing to use MyApp, I've always felt
that speed is of paramount importance.

Have a nice holiday.