direct synchronisation over internet

[Supicek]

Hi,
my app is splitted into BE and FE. The BE includes only tables. We have 9
users regularly (once a week) synchronise BE. 5 of them make the synch in
the office (over LAN), but the other 4 make synch over internet and VPN.

From the other posting I found that I should use INDIRECT synchronisation
method, but as it was much easier to build in the DIRECT method I decided to
try first the DIRECT method even for users who are making synch over
internet. Surprisingly I have not seen any difficulties so far (using the
app for almost 3 months). The BE is not big (4 MB) and unlikely will exceed
10 MB in the following 12 months. Remote users have access to the internet
using the line at least 256 kbps. The synchronisation over LAN takes about 2
sec, over internet in average 3 min (the slowest one took 20 min, this was
exception).

Would you suggest to move the app into INDIRECT synch method, although the
DIRECT method works fine for us so far? Is there any other limitation /
threat I am not aware of?

thank you for your advices.

 

[David W. Fenton]

my app is splitted into BE and FE. The BE includes only tables.
We have 9 users regularly (once a week) synchronise BE. 5 of them
make the synch in the office (over LAN), but the other 4 make
synch over internet and VPN.

From the other posting I found that I should use INDIRECT
synchronisation method,

Internet synchronization is also a possibility but has a hard-wired
dependency on IIS on your HTTP server.

but as it was much easier to build in the DIRECT method I decided
to try first the DIRECT method even for users who are making
synch over internet.

This is an extremely dangerous thing to do. The reason for this is
that a direct synch opens the remote database across the wire. Even
the slightest glitch at any point before the synch completes will
corrupt the remote database in a fashion that will prevent it from
ever synching again with any of the other replicas. And you could
also conceivably lose actual data in the remote replica.

Secondly, it's VERY VERY SLOW in comparison to either of the
alternative methods, since it has to pull the whole remote DB across
the wire. The other methods send only the changes, and don't open
the other database across the wire.

Surprisingly I have not seen any difficulties so far (using the
app for almost 3 months).

This may very well be the case right up until the point that it
breaks. Indirect and Internet replication can *never* corrupt your
replicas, ever, so if you value your data at all, you need to use
one of those methods (and I recommend indirect over Internet).

The BE is not big (4 MB) and unlikely will exceed
10 MB in the following 12 months. Remote users have access to the
internet using the line at least 256 kbps. The synchronisation
over LAN takes about 2 sec, over internet in average 3 min (the
slowest one took 20 min, this was exception).

Would you suggest to move the app into INDIRECT synch method,
although the DIRECT method works fine for us so far? Is there any
other limitation / threat I am not aware of?

It is incredibly foolish to use DIRECT replication if you are aware
of the dangers. You are going to end up responsible for any data
loss that should ever happen and will have to oversee recovering the
data from the remote replica and figuring out how to synch its data
by hand with the other replicas. This is not a trivial task.

There is no excuse for continuing to do what you're doing once you
understand the risk.

Continue doing so only if your data is completely valueless to you.

And you are willing to work for free for the many hours it will take
to recover from any corruption that ever occurs.

And it's not a matter of *if* the corruption will happen, but
entirely a matter of WHEN.

 

[David W. Fenton]

direct method an implement it.
I hope I can write a VBA code in a similar way as for direct
synch, so the users will just press one button.

Well, you *can*, but it depends on a number of outside components:

1. the Jet synchronizer has to be installed on the machine and it
has to be initialized (running it once does part of the
initialization).

2. the dropbox for the local machine has to be set up and its NTFS
security settings correctly configured.

3. this information has to be synchronized with the other replicas
so that they know about the existing synchronizers to be used for
indirect replication.

Once all that is in place on each machine that you want to initiate
a synch from, the code is pretty simple, yes (start the
synchronizer, run the synch, close the synchronizer). It's easiest
to use the TSI Synchronizer, in my opinion, but some people won't
use "unsupported" code, despite the fact that (in my opinion),
Michael Kaplan's unsupported code is often superior to a lot of
developers' fully supported code.

The key difficulty is in setting up the individual workstations,
which without custom tools to do that, is a labor-intensive process.