|
|
|
date: Thu, 15 Nov 2007 13:20:02 -0600,
group: microsoft.public.access.replication
back
Re: Question about potential for corruption when doing direct sync over a WAN
user@domain.invalid wrote in
news:eb#vlY9JIHA.4476@TK2MSFTNGP06.phx.gbl:
> David W. Fenton wrote:
>> user@domain.invalid wrote in
>> news:uSN$Ay7JIHA.3516@TK2MSFTNGP02.phx.gbl:
>>
>>> 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.
> 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?
> 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?
> 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.
> 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.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
date: Fri, 16 Nov 2007 16:19:51 -0600
author: David W. Fenton lid
Re: Question about potential for corruption when doing direct sync
over a WAN
David W. Fenton wrote:
> user@domain.invalid wrote in
> news:eb#vlY9JIHA.4476@TK2MSFTNGP06.phx.gbl:
>
>> David W. Fenton wrote:
>>> user@domain.invalid wrote in
>>> news:uSN$Ay7JIHA.3516@TK2MSFTNGP02.phx.gbl:
>>>
>>>> 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.
>
date: Fri, 16 Nov 2007 18:04:00 -0600
author: lid
Re: Question about potential for corruption when doing direct sync over a WAN
user@domain.invalid wrote in
news:eQuDT1KKIHA.3916@TK2MSFTNGP02.phx.gbl:
> David W. Fenton wrote:
>> 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.
Well, you can prohibit that by having your synchronization routine
check the Forms collection to see how many forms are open. You could
do one of two things:
1. loop through the open forms and close any of them that should not
be open (you'd leave the synchronization dialog, if you've got one,
and your main switchboard form), OR
2. check each form to see if it's dirty and save it if it is. That
would prohibit any replication errors.
> 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.
Your synch code should prevent the user from doing things that are
potentially bad for your data. During a synch, your code should
either close the other open forms, or save their data.
> I saw another user's code that used a form setting for force the
> current form to retain focus until it was closed.
Eh? You mean a modal form? All you have to do is open it with the
acDialog argument to DoCmd.OpenForm and no other form can get the
focus until the form is closed or hidden.
> I may pursue this.
I'm surprised you're not using it all over your app. All Access
forms that function as dialog boxes should be modal.
> 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).
From what form?
> Any good way to trap un-graceful shutdown of Access (e.g. the red
> "x" )and stop such?
Well, no, not really, as it can always be shut down from Task
Manager. But you can do things like saving all open forms before the
app quits. You can also prevent the user from quitting without going
through the QUIT command on your main menu. Or you can use a hidden
form that does all this in its OnClose event.
>>> 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.
The "old" techniques have long been documented. See my Jet
Replication Wiki for pointers:
http://dfenton.com/DFA/Replication/
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
date: 17 Nov 2007 23:00:48 GMT
author: David W. Fenton lid
Re: Question about potential for corruption when doing direct sync
over a WAN
David W. Fenton wrote:
> user@domain.invalid wrote in
> news:eQuDT1KKIHA.3916@TK2MSFTNGP02.phx.gbl:
>
>> David W. Fenton wrote:
>>> 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.
>
> Well, you can prohibit that by having your synchronization routine
> check the Forms collection to see how many forms are open. You could
> do one of two things:
>
> 1. loop through the open forms and close any of them that should not
> be open (you'd leave the synchronization dialog, if you've got one,
> and your main switchboard form), OR
>
> 2. check each form to see if it's dirty and save it if it is. That
> would prohibit any replication errors.
>
>> 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.
>
> Your synch code should prevent the user from doing things that are
> potentially bad for your data. During a synch, your code should
> either close the other open forms, or save their data.
>
>> I saw another user's code that used a form setting for force the
>> current form to retain focus until it was closed.
>
> Eh? You mean a modal form? All you have to do is open it with the
> acDialog argument to DoCmd.OpenForm and no other form can get the
> focus until the form is closed or hidden.
>
>> I may pursue this.
>
> I'm surprised you're not using it all over your app. All Access
> forms that function as dialog boxes should be modal.
>
>> 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).
>
> From what form?
>
>> Any good way to trap un-graceful shutdown of Access (e.g. the red
>> "x" )and stop such?
>
> Well, no, not really, as it can always be shut down from Task
> Manager. But you can do things like saving all open forms before the
> app quits. You can also prevent the user from quitting without going
> through the QUIT command on your main menu. Or you can use a hidden
> form that does all this in its OnClose event.
>
>>>> 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.
>
> The "old" techniques have long been documented. See my Jet
> Replication Wiki for pointers:
>
> http://dfenton.com/DFA/Replication/
>
David -
thanks again for your continued help. I realize now that if my users
don't follow the instructions, they can close the app with forms open.
and I automatically sync upon close. I tried forcing such myself and
got an error 3218. One time but not another time. so clearly this
could cause some of the problems I am experiencing.
as you suggested I just added a routine before the sync on close of the
app, to review all the open forms and close any still open. that should
plug this hole.
Thanks again for the time you spend responding to my questions!!
Bob
date: Sun, 18 Nov 2007 16:40:21 -0600
author: lid
|
|
