|
|
Over the weekend all of my backends (replica farm of 3 and 35 remote
users) created two conflict tables - MsysRepInfo_Conflict and
MsysSchedule_Conflict. I'm not sure why but I cannot resolve them.
The Conflict Viewer says "No Conflict Tables." Since they are Msys
tables it will not allow me to delete them. The info in the conflict
tables don't really identify anything that is specific.
Any suggestions?
Mike
|
|
Mike <iatros56[ at ]hotmail.com> wrote in
news:1182169427.776200.131340[ at ]n2g2000hse.googlegroups.com:
[Quoted Text] > Over the weekend all of my backends (replica farm of 3 and 35
> remote users) created two conflict tables - MsysRepInfo_Conflict
> and MsysSchedule_Conflict. I'm not sure why but I cannot resolve
> them. The Conflict Viewer says "No Conflict Tables." Since they
> are Msys tables it will not allow me to delete them. The info in
> the conflict tables don't really identify anything that is
> specific.
>
> Any suggestions?
What about MSysConflicts? Can you delete it?
It's very strange. You say "all of my backends," so it's clear
you've split your app and have only data tables in the replica set,
so that's not it.
MSysRepInfo is the table with information about the current replica.
It's very weird to think that all replicas would get an edit to
that, unless, say, the ReplicaID changed in all of them.
You might try changing your synch schedule to see if that would
unlock something in the MSysSchedule table.
Last of all, you say you can't delete the conflict tables, but can
you delete the conflict records?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
David,
Thanks for your reply. The MsysConflicts is holding 12 records. The
reason listed says, "Recovered replicable data. This row was recovered
from a corrupted replicable database. Verify that the record contents
are correct and then reinsert the record, or delete this conflict
record."
I never looked in there...stupid me. Anyway, it will not let me
delete any of the records. It says they are read only. I tried from
the Design Master and one of the replicated databases on my computer.
The winning and losing replica fields are blank - so I can't determine
which replica it is involving.
Mike
|
|
Mike <iatros56[ at ]hotmail.com> wrote in
news:1182259362.906606.149010[ at ]w5g2000hsg.googlegroups.com:
[Quoted Text] > The MsysConflicts is holding 12 records. The
> reason listed says, "Recovered replicable data. This row was
> recovered from a corrupted replicable database. Verify that the
> record contents are correct and then reinsert the record, or
> delete this conflict record."
>
> I never looked in there...stupid me. Anyway, it will not let me
> delete any of the records. It says they are read only. I tried
> from the Design Master and one of the replicated databases on my
> computer. The winning and losing replica fields are blank - so I
> can't determine which replica it is involving.
Well, the answer I guess is to compact all your replicas. I don't
know when those records will disappear, though. I think the table is
deletable, though.
It may be that the records are deletable only at the problem
replica, or at the replica that synched with the problem replica.
Interesting problem! I've never seen or heard of this one before,
ever.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Thanks David. I'll work through each of the replicas and let you know
what happens.
As always, I appreciate your assistance and expertise.
Mike
|
|
Mike <iatros56[ at ]hotmail.com> wrote in
news:1182353352.484616.161850[ at ]q75g2000hsh.googlegroups.com:
[Quoted Text] > I'll work through each of the replicas and let you know
> what happens.
Please post back here so there's a public record in case anyone else
runs into the problem, too.
> As always, I appreciate your assistance and expertise.
Hey, we're all just trying to figure out how it all works!
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
David,
Well, we've gone through all the replicas (35 computers - 3 replicas
on each) and actually direct synced each one of them with the Design
Master (I was desperate!!). The two Msys conflict tabes remain. In
fact, over the past week we have had a couple of replicas
"unreplicate" themselves during the daily compact routine and about 12
that became corrupt. So, I think we need to unreplicate and re-
replicate the Design Master and start from scratch. This was not a
light decision. This takes down the entire company for a few hours
(we're a 24/7 medical company) and we'll have to download the new
replica (500 MB) to the remote sites (about 30 of the 35 computers).
We're starting Saturday.
We are using the Microsoft Replication Conflict Viewer and I am
thinking about adding my own conflict resolver. However, I have a
question. Jet 4.0 is new to me - as we have been using Access 97
until just recently. With Microsoft's Conflict Viewer, If a conflict
occurs on my computer and I clear it does my choice propagate
throughout the topology and clear on all 35 computers, or does the
conflict have to be cleared on each and every computer? I'd like to
be able to have all conflicts "centrally" located and reviewed and
cleared through one person.
Thanks David.
Mike
|
|
Mike <iatros56[ at ]hotmail.com> wrote in
news:1183060375.088340.71430[ at ]u2g2000hsc.googlegroups.com:
[Quoted Text] > Well, we've gone through all the replicas (35 computers - 3
> replicas on each) and actually direct synced each one of them with
> the Design Master (I was desperate!!). The two Msys conflict
> tabes remain. In fact, over the past week we have had a couple of
> replicas "unreplicate" themselves during the daily compact routine
> and about 12 that became corrupt.
The loss of replication is a sign that the replica was corrupted.
> So, I think we need to unreplicate and re-
> replicate the Design Master and start from scratch. This was not
> a light decision. This takes down the entire company for a few
> hours (we're a 24/7 medical company) and we'll have to download
> the new replica (500 MB) to the remote sites (about 30 of the 35
> computers). We're starting Saturday.
How could corruption develop in your replicas? That's the key
question, seems to me.
For what it's worth, I've been doing replication since 1997, and
have not once seen the problem you've encountered.
I've seen corruption that resulted in loss of replication, but never
the error you reported.
> We are using the Microsoft Replication Conflict Viewer and I am
> thinking about adding my own conflict resolver. However, I have a
> question. Jet 4.0 is new to me - as we have been using Access 97
> until just recently.
Hold on a moment. Was the problem you had in a Jet 3.5 replica set?
Did I know that when I replied earlier?
> With Microsoft's Conflict Viewer, If a conflict
> occurs on my computer and I clear it does my choice propagate
> throughout the topology and clear on all 35 computers, or does the
> conflict have to be cleared on each and every computer? I'd like
> to be able to have all conflicts "centrally" located and reviewed
> and cleared through one person.
Jet 4 added two major replication features:
1. universal reporting and resolution of all conflicts, AND
2. field-level conflict resolution.
Moving to Jet 4 might eliminate the vast majority of your conflicts
in the first place, but it would also make it much easier to resolve
them, particular if you have a star topology, where one or two hub
replicas are synching with all the remote replicas.
All that said, you should really pin down what caused the corruption
in the first place (i.e., figure out which replicas were corrupt)
and the fix whatever was causing it, or you may be back where you
started.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
[Quoted Text] > The loss of replication is a sign that the replica was corrupted.
> How could corruption develop in your replicas? That's the key
> question, seems to me.
I guess that's the $64,000 question. It appears to occur during the
compact routine.
I have it set up to where the system compacts the 3 back-ends once
daily. It's a simple
db.CompactDatabase routine. It's called when the front-end has been
inactive for
more than 30 minutes. The front-end closes, compacts the three back-
ends, and then
reopens the front-end.
> For what it's worth, I've been doing replication since 1997, and
> have not once seen the problem you've encountered.
>
> I've seen corruption that resulted in loss of replication, but never
> the error you reported.
> Hold on a moment. Was the problem you had in a Jet 3.5 replica set?
> Did I know that when I replied earlier?
No - it's 4.0. I migrated from 3.5 to 4.0 about two weeks ago and
everything was working fine for
about one week before I received the Msys conflicts.
> Jet 4 added two major replication features:
>
> 1. universal reporting and resolution of all conflicts, AND
>
> 2. field-level conflict resolution.
I have it set up to use column-level which is a fantastic feature!!
> Moving to Jet 4 might eliminate the vast majority of your conflicts
> in the first place, but it would also make it much easier to resolve
> them, particular if you have a star topology, where one or two hub
> replicas are synching with all the remote replicas.
Yes - we are using the star topology
>
> All that said, you should really pin down what caused the corruption
> in the first place (i.e., figure out which replicas were corrupt)
> and the fix whatever was causing it, or you may be back where you
> started.
We did not have the problem in 3.5. I had the database up and
operational since 2001.
The only reason why we migrated to 4.0 was for the additional back-end
size (1 GB to 2 GB) and to use the new column-level tracking.
Mike
|
|
Mike <iatros56[ at ]hotmail.com> wrote in
news:1183120491.807379.72650[ at ]m36g2000hse.googlegroups.com:
[Quoted Text] >> The loss of replication is a sign that the replica was corrupted.
>
>> How could corruption develop in your replicas? That's the key
>> question, seems to me.
>
> I guess that's the $64,000 question. It appears to occur during
> the compact routine.
Actually, that's *very* unlikely. The compact reveals pre-existing
corruption, but it can't possibly cause it. The loss of replication
from a compact is a sign that the replica was corrupted before the
compact began.
> I have it set up to where the system compacts the 3 back-ends once
> daily. It's a simple
> db.CompactDatabase routine. It's called when the front-end has
> been inactive for
> more than 30 minutes. The front-end closes, compacts the three
> back- ends, and then
> reopens the front-end.
I think that's way too often to be compacting any MDB, unless it's
under extreme stress with hundreds or thousands of additions per
day.
That said, the frequent compacts are only revealing corruption
caused by something else, so lowering the frequency of compacting is
not really a solution to the underlying problem -- it would only
reduce the frequency of the problem.
>> For what it's worth, I've been doing replication since 1997, and
>> have not once seen the problem you've encountered.
>>
>> I've seen corruption that resulted in loss of replication, but
>> never the error you reported.
>
>> Hold on a moment. Was the problem you had in a Jet 3.5 replica
>> set? Did I know that when I replied earlier?
>
> No - it's 4.0. I migrated from 3.5 to 4.0 about two weeks ago and
> everything was working fine for
> about one week before I received the Msys conflicts.
That's what I thought -- I had it in my head that you were on Jet 4.
[]
>> All that said, you should really pin down what caused the
>> corruption in the first place (i.e., figure out which replicas
>> were corrupt) and the fix whatever was causing it, or you may be
>> back where you started.
>
> We did not have the problem in 3.5. I had the database up and
> operational since 2001.
> The only reason why we migrated to 4.0 was for the additional
> back-end size (1 GB to 2 GB) and to use the new column-level
> tracking.
Well, what's your front-end version? If it's A2K, then you
definitely need to have at least SR1 installed. So far as I know,
the release versions of A2K2 and A2K3 were stable, but the release
version of A2K was basically unusable and caused horrid and frequent
corruption.
Do you have Jet 4 SP 6 or later on all workstations? You probably
do, as Windows Update would take care of that for Windows, but it's
worth a check.
I've seen lots of corruption in A2K *until* all workstations (and I
mean *all* are brought up to SR1 for Access and Jet 4 SP6 or later.
After that, no curruption at all.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
David,
I think I found out what the underlying problem was. As I mentioned,
the FE and the BEs were in Access 97. I converted both to Access 2003
(Jet 4.0 SP8). I converted the BE originally from 97 to 2003 in the
replicated state. I figured this was not the best way to do it - in
that it defaulted to row tracking instead of column tracking. So, I
unreplicated the BE, converted it to 2003 and then re-replicated it.
I think this was the problem. I used Trigeminal's unreplication
tool. However, I didn't realize that it did not remove the system
fields in each of the tables. Therefore, when I re-replicated it
must have corrupted the Design Master. It was just a matter of time
(about one week to be exact) before everything fell apart.
Today, I took the Design Master, unreplicated it using Pacific
Database PTY Limited's Unreplication Tool - which takes out all the
system fields as well (I couldn't get Trigeminal's Replication System
Fields Utility to work). I then replicated it and redistributed it.
Although it's only been a few hours, I've already noticed that the
process went better than the first time. I really believe by keeping
the original System Fields from 97 when I converted to 2003 caused all
my problems.
I hope this helps others. It was a mess for me.
Thanks for all your help David.
Mike
|
|
|