MA*******@gmail.com wrote in
news:11**********************@t39g2000cwt.googlegr oups.com:
I am a Mainframe guy. I am working with MS access(maintaining a
application) for the last 2 weeks.
I had one master database and four replicas. One of my replica had
trouble in synchronization(It said, database is in use..). After
searching google, I ran "Compact and repair" utlity against my
replica. It looks like, it has changed the attribute of my
replica.
It is very common that when a replica gets flagged as corrupted, it
loses replicability after a compact. The solution is to get rid of
the problem that caused the replica to be flagged as corrupt (it
probably wasn't actually corrupt, just flagged as suspect).
When I try to sycnhronize, I get the below error message
- "Synchronizing with a non-replicated database is not allowed.
The
<name> database is not a Design Master or replica"
Please let me know your views as early as possible. I would really
appreciate each and every response. I value it.
The replica is no longer part of the replica set. You'll need to
recover manually any data unique to it and then create a new replica
to replace it. Before you do that, you want to make sure the
original replica is deleted from the replica set (since you're about
to create a new replica with the same name in the exact same
location). This is done by initiating a direct synch with the
deleted replica from the Access synhconization UI. When you receive
the "replica has been deleted" prompt, you should then synch around
the full replica set (to pass on the information about the deleted
replica to the other replicas), and only then create your new
replica.
There is no easy way to recover from the lost replicability. If you
have time/date stamps on your records and you know when your last
synch was, that makes it a lot easier. If you don't, then you're
stuck looking at the generation numbers (one of the replication
fields) and working from there. It's a lot harder to do it that way,
unfortunately.
But the key issue is: eliminate the cause of the corruption. This
can be quite hard to do. Corruption is not a replication issue, and
here is a page that gives you just about all the advice you need to
troubleshoot corruption:
http://www.granite.ab.ca/access/corruptmdbs.htm
I have run into exactly what you've experienced, back in 1998 or so.
In that case, the cause of the corruption was an Exchange Server
hotfix applied to the server where the problematic replica was
stored. Backing out the hotfix restored the server to reliably
operation and the corruption completely went away. This was OK, as
Exchange Server wasn't even being used (it shouldn't have been
running at all, but the consultants involved were clearly complete
idiots).
That's a fairly exotic cause, but it is the example I often cite of
how a change in software environment that appears to be completely
unrelated to Access/Jet can cause corruption.
But work through Tony's corruption FAQ, and come back to us for
clarifications.
--
David W. Fenton
http://www.dfenton.com/
usenet at dfenton dot com
http://www.dfenton.com/DFA/ 
