Re: Homegrown synchronization

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Here's some other issues that have come up in the course of doing this.

1)The problem I mentioned earlier about two SyncApps taking over at the
same time. Well now I'm not so sure. I do remember that when that
happened one of the SyncApps that had a message saying it was the
manager had also suffered a connection failure. I'm now beginning to
think that it wasn't a manager. In fact a short time later, the other
SyncApp that said it was the manager applied an update to the server
backend while supposedly two SyncApps were managing it.

Under the assumption that the SyncApp is relatively simple coding and
that virtually all errors will be network related, I've added code in
the error handler that if an error occurs, drop the connection for that
SyncApp to place it in non-managing status. Then another SyncApp will
need to take over (if there is one available).

I'm beginning to realize that I have serious LAN connection problems
with my development machine. Actually that's good for now because it
is allowing me to ferret out potential problems. After I implemented
the code in the error handler, the dropped connection to the server (my
development machine) happened again. This time the SyncApp on the
dropped connection machine relinquished management and within the next
timer cycle (currently 1 minute) another SyncApp picked it up.

2) Question about how to use FileCopy. I currently check that the file
to copy exists then I kill the file to be copied over and thereafter
accomplish the FileCopy using the target name as the same name of the
copy I just killed.

But if FileCopy fails, I've lost the original. I'm curious as to how
you would do this. It probably would be better to rename the copy to
be copied over, accomplish the FileCopy and then kill the renamed copy
if FileCopy succeeds. I guess I would need to restore the renamed copy
if FileCopy fails; so that might mean knowing all the possible error
codes.

3) I found out that users have registered copies of WinZip on their
machines (yoohoo!!).

Now I have some questions related to this. With WinZip when a zipped
file is to be unzipped users get to answer Yes, Yes To All, No, etc.
After my code calls the Unzip routine, it writes a record to the table
that that zipped file was unzipped, so that the code doesn't keep
trying to unzip the same file every time it is invoked. The problem is
if the user answers 'No' to Winzip or Winzip fails, that update can no
longer be applied by the code as written, because the code doesn't know
this happened (since it is an external app event). So a record always
gets written to the table that the file was unzipped.

One way to handle this is to give remote users the ability to open the
UpdateInbox and select files to try and unzip. A kind of last resort
method. But if users select poorly, they might update the local backend
file with really old data and that could cause problems.

This is not a very satisfactory option. Any thoughts on how to handle
the WinZip failing or User answering 'No' to Winzip messagebox? If I
could trap those events, then the code would not write the record to
the table. The next time around code would try to unzip it again.

4) I have added menu items to allow users to check if Updates are
available on the server and download the zip file and also to send out
updates from the remote machine. Previously these actions only
occurred on opening the Myapp and closing the MyApp respectively.

Now I know you don't agree with simply replacing the local backend with
the zipped backend downloaded from the server. But this is just a
general question.

The tricky part in doing something like this is that one is trying to
replace a backend file that MyApp is currently connected to. Errors
will occur.

So the way I'm getting around this is by doing two things:

a) Alert the user that all forms will be closed. If they agree all
forms are closed.

b) Invoking three lines of code to close all open recordsets.

In doing this, I find that the FileCopy over the existing local backend
file proceeds without a problem (at least so far).

Now I'm not saying that I'm going to continue to do this (I'm still
considering your other suggestion). I'm just curious that if one were
to do this is this the right way or have I missed something.

5) Creating the update file to send from the remote copy to the server
is taking a relatively long amount of time. Virtually all of it is due
to the method for determining which records were deleted. Just to
refresh reader's memories, this non-Jet synchronization method is being
implemented well after the app has been coded. Currently, deleted
records from tables are deleted; we are not using a DeleteFlag in
tables.

So this means that the only way I can think of to check for deletes
without adding code to the already coded app, is to compare the current
state of the local backend file with a copy of the backend file that
was made at session start. The code looks for differences but it has
to go through every table to do it; that makes it relatively slow.

After thinking about it, I realized that although I have about 100
tables, there are really only four very large tables. So I added some
code to ignore these four tables and ran the createUpdateFile code
again. The time was cut in half to accomplish this.

So for these four tables I may actually add some code to handle deletes
for the update file immediately when the user actually deletes records
from those tables. Then in my CreateUpdateFile code the code will
ignore those tables and that will speed it up substantially. This
needs more thought but is a possibility.


Thanks.

.