Re: Question about potential for corruption when doing direct sync over a WAN

David W. Fenton wrote:
user@xxxxxxxxxxxxxx wrote in
news:eb#vlY9JIHA.4476@xxxxxxxxxxxxxxxxxxxx:

David W. Fenton wrote:
user@xxxxxxxxxxxxxx wrote in
news:uSN$Ay7JIHA.3516@xxxxxxxxxxxxxxxxxxxx:

I have read about not doing a direct sync over a wan because of
the potential for corruption. As I understand it, the replica
that is not local to the requesting replica is copied across the
link and updates are made in both direction. I also understand
that if the link breaks or disconnects, that corruption can
occur.

My question is whether the potential for corruption is on both
replicas or only the one at the far end, which had to send data
in blocks across the link?
The potential for corruption is in the remote replica, though I
guess it could happen in the local one, too.

Direct synchs should never be done over a non-wired LAN
connection of anything less than 10Mbps bandwidth.

My interest is in how it could happen to the local one.

Well, corruption can happen on a local LAN in replicated and
non-replicated apps, and doesn't necessarily happen because of a
dropped connection. All sorts of things can cause the problem, such
as bad Jet versions, or non-optimal versions of the MS Access
program file.
I am also pursuing the possibility of hibernation or suspension as well as shutting down the PC un-gracefully as possible causes. I may put in some added data to the syncs that occur when the user starts up and shuts down to see if I always get pairs of such for laptops that get corrupted databases.

why I ask is as part of my trying to figure out some cases - 3 -
of database corruption on laptop based replicas. The replica on
the laptop which initiates the sync to the LAN - is the one where
the corruption occurs. Never on the LAN!

Do you have memo fields stored in your replicated tables? Are the
users allowed to synch while they have forms open?
Yes I have memo fields.

The users are NOT supposed to synch while any form is open.
But if they got creative they could. I have a sync button on the main menu. All submenus and forms are accessed in a hierarchical path. They are supposed to follow the hierarchy back to the main menu. but they could look at the list of open forms at the bottom of their screen and
select the Main Menu and then use the sync button while a form was open.

I saw another user's code that used a form setting for force the current form to retain focus until it was closed. I may pursue this.
I think I will also remove the sync button from the form (I added it in response to client project manager who like her staff was peranoid about losing data).

Any good way to trap un-graceful shutdown of Access (e.g. the red "x" )and stop such?



As I have been considering problems of networking hardware or LAN connectivity as a potential cause for the corruption, that is why
I have asked.

It doesn't sound like that would be the case, given that it's the
local replica being corrupted. I assume the synch is being initiated
*from* the laptop?
Correct.


I would sure like to know from any MVP who might have access to
some of the Microsoft restricted newsgroup items and/or access to
some of the Microsoft Access team, if you can get corruption at
the replica initiating the sync in the case of a failed sync due
to connectivity.

Chances are, nobody who is a current MVP knows these things, as
nobody does Jet Replication any longer.
Oh well, I am an old fa** so I don't mind using old techniques.


My thought is if I could rule this out then I could pursue other possibilities such as the user shutting down the laptop with the database still open.

A chief cause of replication corruption is running a synch while a
memo field is in a state of being edited.

.