By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,853 Members | 1,541 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,853 IT Pros & Developers. It's quick & easy.

Replication: very strange problem

P: n/a
Hi

I have a client running an Access 2000 database on a small network
with 3 pc's. Two of the laptop pcs have a data replica, which they
use when not connected to the network, the 'server' being the 3rd
machine.

The other day they reported that 'suddenly' a whole load of data that
they had entered (on to the 'server' main data) that day had
'disappeared'. Not only had the new data gone, but updates performed
when the new data was entered seemed to have rolled back (e.g. items
on new invoices were back in stock again).

The information they gave me was somewhat vague, but they did say that
when preparing one of the invoices, they suddenly saw 'Error' in all
the fields and crashed out. When they went back in again, the day's
work had disappeared. I went over there and couldn't see any evidence
of this work on any machine, including the 2 replica databases and it
seemed inexplicable.

However, I now suspect that what must have happened is that one of
them tried to synchronise their laptop whilst the others were entering
data - obviously not a good idea. Could it be that somehow the main
data (which is the design master) got corrupted in such a way that it
was OVERWRITTEN with the earlier replica, and therefore the newer
records were lost? It seems that the data has returned to the state
it was in when this person last synchronised.
Could this be possible? And if so, how could it happen and how can it
be avoided? Help!

Many thanks.

Ondine.
Nov 13 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On 29 Sep 2004 07:24:48 -0700, os*******@yahoo.co.uk (Ondine) wrote:

Rather than speculating what happened, restore a backup.
-Tom.

Hi

I have a client running an Access 2000 database on a small network
with 3 pc's. Two of the laptop pcs have a data replica, which they
use when not connected to the network, the 'server' being the 3rd
machine.

The other day they reported that 'suddenly' a whole load of data that
they had entered (on to the 'server' main data) that day had
'disappeared'. Not only had the new data gone, but updates performed
when the new data was entered seemed to have rolled back (e.g. items
on new invoices were back in stock again).

The information they gave me was somewhat vague, but they did say that
when preparing one of the invoices, they suddenly saw 'Error' in all
the fields and crashed out. When they went back in again, the day's
work had disappeared. I went over there and couldn't see any evidence
of this work on any machine, including the 2 replica databases and it
seemed inexplicable.

However, I now suspect that what must have happened is that one of
them tried to synchronise their laptop whilst the others were entering
data - obviously not a good idea. Could it be that somehow the main
data (which is the design master) got corrupted in such a way that it
was OVERWRITTEN with the earlier replica, and therefore the newer
records were lost? It seems that the data has returned to the state
it was in when this person last synchronised.
Could this be possible? And if so, how could it happen and how can it
be avoided? Help!

Many thanks.

Ondine.


Nov 13 '05 #2

P: n/a
Tom

The reason I am speculating is because I don't need this happening
again. They are a disorganised and difficult client, and in my
experience it helps in terms of one's credibility to be able to
explain what might have gone wrong and take steps to avoid it
recurring.

Ondine.

Tom van Stiphout <no*************@cox.net> wrote in message news:<6j********************************@4ax.com>. ..
On 29 Sep 2004 07:24:48 -0700, os*******@yahoo.co.uk (Ondine) wrote:

Rather than speculating what happened, restore a backup.
-Tom.

Hi

I have a client running an Access 2000 database on a small network
with 3 pc's. Two of the laptop pcs have a data replica, which they
use when not connected to the network, the 'server' being the 3rd
machine.

The other day they reported that 'suddenly' a whole load of data that
they had entered (on to the 'server' main data) that day had
'disappeared'. Not only had the new data gone, but updates performed
when the new data was entered seemed to have rolled back (e.g. items
on new invoices were back in stock again).

The information they gave me was somewhat vague, but they did say that
when preparing one of the invoices, they suddenly saw 'Error' in all
the fields and crashed out. When they went back in again, the day's
work had disappeared. I went over there and couldn't see any evidence
of this work on any machine, including the 2 replica databases and it
seemed inexplicable.

However, I now suspect that what must have happened is that one of
them tried to synchronise their laptop whilst the others were entering
data - obviously not a good idea. Could it be that somehow the main
data (which is the design master) got corrupted in such a way that it
was OVERWRITTEN with the earlier replica, and therefore the newer
records were lost? It seems that the data has returned to the state
it was in when this person last synchronised.
Could this be possible? And if so, how could it happen and how can it
be avoided? Help!

Many thanks.

Ondine.

Nov 13 '05 #3

P: n/a
Tom van Stiphout <no*************@cox.net> wrote in
news:6j********************************@4ax.com:
Rather than speculating what happened, restore a backup.


Restoring backups is problematic with replication. Consider this
scenario:

1. you have three replicas. You synch the three so they are all
identical.

2. data is edited in replica1 and synched with the other two
replicas.

3. data is also edited in replica2 and replica3, but replica1 is
corrupted and lost.

4. you restore a backup of replica1 that predates the
synchronization with the other two replicas.

Consider the state of affairs:

Replica2 and replica3 already know about data from replica1 that the
restored version of replica1 doesn't even have in it.

What should synchronization do when a replica reverts to a
generation earlier than is recorded in the other replicas in the
replica set

I can't predict what will happen, and because of that, you should be
very wary of restoring a backup of a replicated database.

This is why MichKa recommends the use of what he calls "Replica
Farms." The concept is that around each replica that is in use, you
have a farm of expendable replicas that are kept in synch on a
regular schedule. If your edited replica gets corrupted, you delete
it, synch with the other replicas in the replica farm (so they know
that replica doesn't exist any more and can delete it from their
replication tables), then create a replacement replica. The only
data that will be lost is the data entered between the last synch
and the corruption.

Note to Access developers: if you haven't done replication, you
probably shouldn't give advice about it.

There are any number of non-obvious issues and possible gotchas that
might seem perfectly OK from your experience in a non-replicated
scenario that can cause corruption and major data loss when the same
database/application is replicated.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #4

P: n/a
os*******@yahoo.co.uk (Ondine) wrote in
news:93**************************@posting.google.c om:
I have a client running an Access 2000 database on a small network
with 3 pc's. Two of the laptop pcs have a data replica, which
they use when not connected to the network, the 'server' being the
3rd machine.

The other day they reported that 'suddenly' a whole load of data
that they had entered (on to the 'server' main data) that day had
'disappeared'. Not only had the new data gone, but updates
performed when the new data was entered seemed to have rolled back
(e.g. items on new invoices were back in stock again).
Data can disappear from a replica for three reasons that I can think
of:

1. a user deletes it in one replica. When that replica is synched,
the deletions are properly propagated to the other replicas in the
replica set.

2. a primary key index is corrupted and records then disappear from
recordsets that utilize that index (either selects or sorts; the
sorts don't have to be on the PK, either, since other indexes can
use the PK index for getting to the data pages involved).

3. something corrupts a database and records are lost because of the
corruption.
The information they gave me was somewhat vague, . . .
I've been doing technical support all week, and one of the things
that is being driven home to me (I knew it from experience already)
is that you don't really know what happened until you talk to the
user and interview them at length. I've had many messages like "user
xyz can't retrieve email" that turned out to really be "user xyz is
not on a distribution list for a certain class of email messages
that she thinks she has a right to see."
. . . but they did say
that when preparing one of the invoices, they suddenly saw 'Error'
in all the fields and crashed out. When they went back in again,
the day's work had disappeared. I went over there and couldn't
see any evidence of this work on any machine, including the 2
replica databases and it seemed inexplicable.
That could happen because another user deleted the records while
they were viewing. It could perhaps happen because of a corrupted
index.

It could possibly happen if a synch took place while the user was
editing, but I think this is unlikely. If the records were deleted,
the user wouldn't see #ERROR but #DELETED.
However, I now suspect that what must have happened is that one of
them tried to synchronise their laptop whilst the others were
entering data - obviously not a good idea. . . .
It's a perfectly good idea. Indeed, it's recommended.

The synch is just another user editing the data, no different than a
human user. It's just that the edits happen all in a batch and in
larger numbers than a human being could do in the same amount of
time.

I've never seen corruption from that scenario *except* in the case
of memo fields -- memo fields should all be unbound in replicated
apps (and many would argue that they should be unbound in *all*
apps).
. . . Could it be that
somehow the main data (which is the design master) got corrupted
in such a way that it was OVERWRITTEN with the earlier replica,
Corruption doesn't propagate through replication, as it does not
conform to the necessary schema for recording and propagating the
replication changes.
and therefore the newer records were lost? It seems that the data
has returned to the state it was in when this person last
synchronised. Could this be possible? And if so, how could it
happen and how can it be avoided? Help!


My bet is that it's either corruption or someone trying to cover up
a huge mistake.

My vote would be for the latter.

You might be able to recover some of the data if you restored from a
backup to a new location (not over top of the corrupted file) and
then synched the other replicas with that restored backup (it would
be a new replica in the replica set so it won't cause the problems I
described in my reply to Tom).

But I strongly doubt that's the issue.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #5

P: n/a
On Thu, 30 Sep 2004 20:42:10 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

I do agree with the idea of replica farms, but in lieu of that, I
would restore the master, and recreate the replicas.

I'm on somewhat thin ice here: in my mind replication is too difficult
to manage by all but the most sophisticated clients, so I rarely have
an opportunity to use it :-)

-Tom.

Tom van Stiphout <no*************@cox.net> wrote in
news:6j********************************@4ax.com :
Rather than speculating what happened, restore a backup.


Restoring backups is problematic with replication. Consider this
scenario:

1. you have three replicas. You synch the three so they are all
identical.

2. data is edited in replica1 and synched with the other two
replicas.

3. data is also edited in replica2 and replica3, but replica1 is
corrupted and lost.

4. you restore a backup of replica1 that predates the
synchronization with the other two replicas.

Consider the state of affairs:

Replica2 and replica3 already know about data from replica1 that the
restored version of replica1 doesn't even have in it.

What should synchronization do when a replica reverts to a
generation earlier than is recorded in the other replicas in the
replica set

I can't predict what will happen, and because of that, you should be
very wary of restoring a backup of a replicated database.

This is why MichKa recommends the use of what he calls "Replica
Farms." The concept is that around each replica that is in use, you
have a farm of expendable replicas that are kept in synch on a
regular schedule. If your edited replica gets corrupted, you delete
it, synch with the other replicas in the replica farm (so they know
that replica doesn't exist any more and can delete it from their
replication tables), then create a replacement replica. The only
data that will be lost is the data entered between the last synch
and the corruption.

Note to Access developers: if you haven't done replication, you
probably shouldn't give advice about it.

There are any number of non-obvious issues and possible gotchas that
might seem perfectly OK from your experience in a non-replicated
scenario that can cause corruption and major data loss when the same
database/application is replicated.


Nov 13 '05 #6

P: n/a
David

Thanks very much for your constructive advice. I doubt that we will
ever get to the bottom of what actually happened over there. They
apparantly lost data from 3 different tables (and these records were
not linked at all) so the corrupted index looks unlikely. Also,
related records in other tables lost changes made to them, which is
why I speculated that the data seemed to revert to an earlier version.

Anyway, the replica 'farm' idea sounds interesting and I would be
grateful for any pointers as to where I can find out more about this
concept. I was wondering however if it would be recommended in a
situation where:
a) The 'server' is a basic pc running Windows 98
b) The person working on the 'server' may not have Access 2000
running all the time (or at all)
c) There is no reasonably computer-literate person on-site and I try
to keep my visits to a minimum!

Thanks again.

Ondine.

"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@216.196 .97.142>...
os*******@yahoo.co.uk (Ondine) wrote in
news:93**************************@posting.google.c om:
I have a client running an Access 2000 database on a small network
with 3 pc's. Two of the laptop pcs have a data replica, which
they use when not connected to the network, the 'server' being the
3rd machine.

The other day they reported that 'suddenly' a whole load of data
that they had entered (on to the 'server' main data) that day had
'disappeared'. Not only had the new data gone, but updates
performed when the new data was entered seemed to have rolled back
(e.g. items on new invoices were back in stock again).


Data can disappear from a replica for three reasons that I can think
of:

1. a user deletes it in one replica. When that replica is synched,
the deletions are properly propagated to the other replicas in the
replica set.

2. a primary key index is corrupted and records then disappear from
recordsets that utilize that index (either selects or sorts; the
sorts don't have to be on the PK, either, since other indexes can
use the PK index for getting to the data pages involved).

3. something corrupts a database and records are lost because of the
corruption.
The information they gave me was somewhat vague, . . .


I've been doing technical support all week, and one of the things
that is being driven home to me (I knew it from experience already)
is that you don't really know what happened until you talk to the
user and interview them at length. I've had many messages like "user
xyz can't retrieve email" that turned out to really be "user xyz is
not on a distribution list for a certain class of email messages
that she thinks she has a right to see."
. . . but they did say
that when preparing one of the invoices, they suddenly saw 'Error'
in all the fields and crashed out. When they went back in again,
the day's work had disappeared. I went over there and couldn't
see any evidence of this work on any machine, including the 2
replica databases and it seemed inexplicable.


That could happen because another user deleted the records while
they were viewing. It could perhaps happen because of a corrupted
index.

It could possibly happen if a synch took place while the user was
editing, but I think this is unlikely. If the records were deleted,
the user wouldn't see #ERROR but #DELETED.
However, I now suspect that what must have happened is that one of
them tried to synchronise their laptop whilst the others were
entering data - obviously not a good idea. . . .


It's a perfectly good idea. Indeed, it's recommended.

The synch is just another user editing the data, no different than a
human user. It's just that the edits happen all in a batch and in
larger numbers than a human being could do in the same amount of
time.

I've never seen corruption from that scenario *except* in the case
of memo fields -- memo fields should all be unbound in replicated
apps (and many would argue that they should be unbound in *all*
apps).
. . . Could it be that
somehow the main data (which is the design master) got corrupted
in such a way that it was OVERWRITTEN with the earlier replica,


Corruption doesn't propagate through replication, as it does not
conform to the necessary schema for recording and propagating the
replication changes.
and therefore the newer records were lost? It seems that the data
has returned to the state it was in when this person last
synchronised. Could this be possible? And if so, how could it
happen and how can it be avoided? Help!


My bet is that it's either corruption or someone trying to cover up
a huge mistake.

My vote would be for the latter.

You might be able to recover some of the data if you restored from a
backup to a new location (not over top of the corrupted file) and
then synched the other replicas with that restored backup (it would
be a new replica in the replica set so it won't cause the problems I
described in my reply to Tom).

But I strongly doubt that's the issue.

Nov 13 '05 #7

P: n/a
os*******@yahoo.co.uk (Ondine) wrote in
news:93**************************@posting.google.c om:
Anyway, the replica 'farm' idea sounds interesting and I would be
grateful for any pointers as to where I can find out more about
this concept. . . .
You need to review all the information about replication on Michael
Kaplan's website, http://www.trigeminal.com. One of the articles is
about the concept of Replica Farms.

You also might want to go to Google Groups and check out the
archives of microsoft.public.access.replication.
. . . I was wondering however if it would be recommended in a
situation where:
a) The 'server' is a basic pc running Windows 98
In this day and age, I'd *never* use a Win9x PC as my file server in
a peer-to-peer network -- it's just not nearly stable enough. NT 4
or Win2K or WinXP are vastly superior in regard to stability.
b) The person working on the 'server' may not have Access 2000
running all the time (or at all)
That has nothing whatsoever to do with replication. If you're going
to do a replica farm, you need Replication Manager and the
Synchronizer, which you get with the developer tools.
c) There is no reasonably computer-literate person on-site and I
try to keep my visits to a minimum!


Then consider doing remote administration via a tool like VNC (which
is a free, lightweight program that allows remote control of a PC).
That's how I support my clients.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #8

P: n/a
Thanks for all your advice David. You'll laugh when I tell you that
the 'server' pc has no internet connection (client boss paranoid about
criminals getting hold of his vast fortune) which would rule out VNC
(which I use elsewhere) for now!

However, I will see if I can somehow drag them into the 21st century.

Thanks again.

Ondne.
"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@216.196 .97.142>...
os*******@yahoo.co.uk (Ondine) wrote in
news:93**************************@posting.google.c om:
Anyway, the replica 'farm' idea sounds interesting and I would be
grateful for any pointers as to where I can find out more about
this concept. . . .


You need to review all the information about replication on Michael
Kaplan's website, http://www.trigeminal.com. One of the articles is
about the concept of Replica Farms.

You also might want to go to Google Groups and check out the
archives of microsoft.public.access.replication.
. . . I was wondering however if it would be recommended in a
situation where:
a) The 'server' is a basic pc running Windows 98


In this day and age, I'd *never* use a Win9x PC as my file server in
a peer-to-peer network -- it's just not nearly stable enough. NT 4
or Win2K or WinXP are vastly superior in regard to stability.
b) The person working on the 'server' may not have Access 2000
running all the time (or at all)


That has nothing whatsoever to do with replication. If you're going
to do a replica farm, you need Replication Manager and the
Synchronizer, which you get with the developer tools.
c) There is no reasonably computer-literate person on-site and I
try to keep my visits to a minimum!


Then consider doing remote administration via a tool like VNC (which
is a free, lightweight program that allows remote control of a PC).
That's how I support my clients.

Nov 13 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.