Re: Homegrown synchronization


David W. Fenton wrote:
"rdemyan" <rdemyan@xxxxxxxxxxx> wrote in
news:1167243172.045423.134430@xxxxxxxxxxxxxxxxxxxxxxxxxxx:

[]

b) In order to determine if there are record that were deleted,
the code has to check each table. I don't see how a filter can be
applied in the current setup. That means that the process for over
100 tables is relatively long.

If you used a DELETED flag and left the deleted records in the
tables and just hid them from users in forms and reports and your
processing routines, then you wouldn't have to anything at all,
since the UPDATE process would propagate the DELETED flags.


I've created my own "sync" program (that I mentioned in the earlier
post) that launches with my app but is minimized with no focus. Its
purpose is to work in the background using a form timer to check for
update files in the Import DropBox for the server. Preliminary tests
are showing good results (the code is very similar to the import code
used to update a remote backend). But it's rudimentary and it's
thinking of all the ways people might "break" it, that is probably
where most of the effort is. You noted that I should only allow one
instance to run. I'll have to research how to do that; I've never done
that before.

Also, I'm thinking that when my app gets closed, I won't include code
to close the "sync" app. That way it'll be on the job longer so to
speak, probably until a user, on the LAN with the server, shuts down
their computer.

However, now I'm thinking about how to send out updates from the server
to the remote users. I think the way I will do this is, when the
"sync' program detects update files in the server Import Drop Box, it
will run the code to apply those updates to the server backend. This
already appears to be working fine.

After the import, code will be run in the "sync" program to create an
export update file from the changes applied to the server backend.
This export update file will be stored in the Export DropBox on the
server (as opposed to Import DropBox). This is the server folder where
my app used by remote users will look to find new update files and if
found, copy them to a local PC Import Drop box for processing to update
the local backend file. This too is working.

However, creating this export update file from the server backend file
is where it gets a bit tricky I think. When this update file is
created from a LOCAL backend file, my app just logs the session start
for the app. If when closing the app records are found that have a
Last_Updated date field that is greater than the session start
date/time, then these records are written to the temp updateDB that
will be sent to the server's Import Dropbox.

But for the server backend file this is different. There isn't a
session start time. I guess I'll have to use the last date that a temp
updateDB was created from the server backend as the comparison date.
This info can be stored in the backend file.

Again, though I'll have the same issue with deletes. Your suggestion
about using a delete flag in the tables also occurred to me, but I
dismissed it quickly. However, now that you raise it, I should give it
some consideration. It would have the tremendous advantage of allowing
the code to quickly find the records that were "deleted" for inclusion
in the temp updateDB (essentially it would work the same as finding
updates).

The downside, of course, is the code changes that will be required to
my app. Further I have to add a field to each table (actually I know
how to do this in code, so it's not really a big deal). But not only
does the delete code in the app have to be modified, but all select
code does as well. If it had been designed in at the beginning, not
much of a problem. But at this stage, this seems like a tremendous
amount of work.


Having a human adminstrator apply the updates via your Access code
should be a huge improvement, no? That way you won't have to worry
about all the problems that come with trying to do your updates
automatically.

Huh? You don't mean that what we're doing now with all of the manual
updating and sending out of emails is better than what I'm planning, do
you?

The new ACCDB format does not support replication. Nor does it
support user-level security. However, you can still create MDB files
in A2K7 and replicate them and implement user-level security. So,
from my point of view, it's just about the same, except for the fact
that the new features of the ACCDB format are not available when you
use the "old" format.

Leave it to Microsoft. All the more reason I'm glad I'm making the
decision to handle my
own synchronization, despite the large effort required.

Hope you had a nice holiday!

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

.

Relevant Pages

  • Re: Homegrown synchronization
    ... background on the server like the Jet Synchronizer. ... initiate the updating of the server backend. ... Should I use a hidden form in my app with a timer that monitors ... that MS will abandon Jet replication as they currently seem to be ...
    (microsoft.public.access.replication)
  • AntiVirus update without internet access.
    ... I have been tasked with finding an antivirus software product for a ... This server doesn't have an internet connection, ... wants it to be regularly updated with the latest antivirus ... putting the update file in a specific directory on the server. ...
    (alt.comp.anti-virus)
  • Re: AntiVirus update without internet access.
    ... This server doesn't have an internet connection, ... wants it to be regularly updated with the latest antivirus ... We have some mahcines here that can see our LAN but not the internet, ... putting the update file in a specific directory on the server. ...
    (alt.comp.anti-virus)