replication to designated hub

mckennedy · External Since: Feb 12, 2009 Posts: 1

I am trying to synchronise a replica to a designated hub. The name of the
server that the replica is on has changed and I have recovered the designated
hub using "recover design master". When I go to sychronise the replica
though, it will not sychronise when I browse to the new designated hub-I get
a message "Local or anonymous replicas must only synch to their designated
hub replica". Any way of fixing this?

David W. Fenton · External Since: Dec 25, 2005 Posts: 975

=?Utf-8?B?bWNrZW5uZWR5?= <mckennedy RemoveThis @discussions.microsoft.com> wrote
in news:45A5D82D-AD92-4C3A-BC29-D042579D67DF@microsoft.com:

> I am trying to synchronise a replica to a designated hub. The name
> of the server that the replica is on has changed and I have
> recovered the designated hub using "recover design master". When I
> go to sychronise the replica though, it will not sychronise when I
> browse to the new designated hub-I get a message "Local or
> anonymous replicas must only synch to their designated hub
> replica". Any way of fixing this?

Well, your first mistake was using a local or anonymous replica:

http://trigeminal.com/usenet/usenet027.asp?1033

There is no way to fix it.

And that's precisely why it's a bad idea to ever even contemplate
using them.

If it's not an anonymous or local replica, then you might want to
look at this:

http://trigeminal.com/usenet/usenet016.asp?1033

I have often used an empty partial replica to "wake up" a
replication site that has lost its ability to synch with other
synchronizers. Changing the DM is precisely the kind of situation
where that kind of thing is helpful.

Another point:

Try not to store your DM on a machine whose name is likely to
change. If the server where your DM lives is being replaced with a
new server, then you should use the Jet MoveReplica command to move
it to the new server. This will preserve the original ReplicaID of
the DM and retain all the information about all the other replicas.
Once you've synched from the location you've moved it to, all the
other replicas will be fine.

Unfortunately, MS has made little effort to make the MoveReplica
programatically accessible. It's available through the UI of
Replication Manager, but it's virtually impossible to acquire that
any more. I use the TSI Synchronizer to move replicas, as that's the
only place I know that the command is programmatically exposed.

If JRO had been properly designed, it would have included the
MoveReplica command, but it's quite clear MS didn't take JRO
seriously at all when they created it, as there is virtually no
functionality found there that is not in DAO (the only thing I can
think of is that JRO can initiate an indirect synch in code, while
DAO can't).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Martin Hore · External Since: Nov 04, 2009 Posts: 1

I think I have the same problem as mckenned, following a migration of my design master and all my replicas from one server to another. I even got our server team to re-open the old server from which my design master and replicas had been migrated, and I migrated them back again, but still no joy with synchronisation - I get the identical error message.

So I presume that David Fenton's reply applies to me as well and there is no solution other than a long "manual" reconciliation of the data. Just posting in the hope that I might be wrong.

I apreciate from occasional visits to these forums that Access database replication is not hugely robust, but it has worked reasonably well for me for a couple of years up till now. I do from time to time have to recreate the synchronised database in a new "shell" to avoid a build up of spurious replication data, but apart from that, and occasional odd synchronisation conflicts, it's worked quite well.

mckenned wrote:

replication to designated hub
12-Feb-09

I am trying to synchronise a replica to a designated hub. The name of the
server that the replica is on has changed and I have recovered the designated
hub using "recover design master". When I go to sychronise the replica
though, it will not sychronise when I browse to the new designated hub-I get
a message "Local or anonymous replicas must only synch to their designated
hub replica". Any way of fixing this?

Previous Posts In This Thread:

On 12 February 2009 07:59
mckenned wrote:

replication to designated hub
I am trying to synchronise a replica to a designated hub. The name of the
server that the replica is on has changed and I have recovered the designated
hub using "recover design master". When I go to sychronise the replica
though, it will not sychronise when I browse to the new designated hub-I get
a message "Local or anonymous replicas must only synch to their designated
hub replica". Any way of fixing this?

On 12 February 2009 19:30
David W. Fenton wrote:

=?Utf-8?B?bWNrZW5uZWR5?
=?Utf-8?B?bWNrZW5uZWR5?= <mckennedy.DeleteThis@discussions.microsoft.com> wrote
in news:45A5D82D-AD92-4C3A-BC29-D042579D67DF@microsoft.com:

Well, your first mistake was using a local or anonymous replica:

http://trigeminal.com/usenet/usenet027.asp?1033

There is no way to fix it.

And that's precisely why it's a bad idea to ever even contemplate
using them.

If it's not an anonymous or local replica, then you might want to
look at this:

http://trigeminal.com/usenet/usenet016.asp?1033

I have often used an empty partial replica to "wake up" a
replication site that has lost its ability to synch with other
synchronizers. Changing the DM is precisely the kind of situation
where that kind of thing is helpful.

Another point:

Try not to store your DM on a machine whose name is likely to
change. If the server where your DM lives is being replaced with a
new server, then you should use the Jet MoveReplica command to move
it to the new server. This will preserve the original ReplicaID of
the DM and retain all the information about all the other replicas.
Once you've synched from the location you've moved it to, all the
other replicas will be fine.

Unfortunately, MS has made little effort to make the MoveReplica
programatically accessible. It's available through the UI of
Replication Manager, but it's virtually impossible to acquire that
any more. I use the TSI Synchronizer to move replicas, as that's the
only place I know that the command is programmatically exposed.

If JRO had been properly designed, it would have included the
MoveReplica command, but it's quite clear MS didn't take JRO
seriously at all when they created it, as there is virtually no
functionality found there that is not in DAO (the only thing I can
think of is that JRO can initiate an indirect synch in code, while
DAO can't).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

EggHeadCafe - Software Developer Portal of Choice
UML Interview Question Part 1
http://www.eggheadcafe.com/tutorials/aspnet/8bf1167f-960e-4af4-93db-d1...7fe30be

David W. Fenton · External Since: Dec 25, 2005 Posts: 975

Martin Hore wrote in news:2009114103228martin.hore@suffolk.gov.uk:

> I think I have the same problem as mckenned, following a migration
> of my design master and all my replicas from one server to
> another. I even got our server team to re-open the old server from
> which my design master and replicas had been migrated, and I
> migrated them back again, but still no joy with synchronisation -
> I get the identical error message.

The issue is likely that you didn't legally move the replicas. There
is no getting around that requirement if you want replication to
continue to work reliably.

> So I presume that David Fenton's reply applies to me as well and
> there is no solution other than a long "manual" reconciliation of
> the data. Just posting in the hope that I might be wrong.

I don't know about your particular situation, but if you're using
anonymous or local replicas and the parent replica is no longer
accessible in its original location with its original ReplicaID,
then the data in those anon/local replicas is permanently orphaned
and can never be synched with the rest of the replica set. This is
why I recommend never, ever using anon/local replicas -- the problem
they are designed to solve is one that shouldn't happen in the first
place if you're doing things correctly.

> I apreciate from occasional visits to these forums that Access
> database replication is not hugely robust,

It is as robust as the Jet database engine, and all of its
vulnerabilities come from that source.

> but it has worked reasonably well for me for a couple of years up
> till now. I do from time to time have to recreate the synchronised
> database in a new "shell" to avoid a build up of spurious
> replication data, but apart from that, and occasional odd
> synchronisation conflicts, it's worked quite well.

There should be no "spurious replication data." I can think of only
two types of data that are undesirable:

1. excessive numbers of records in MSysTombstone

2. large numbers of dead replicas.

Both of these happen when you're doing things wrong, and the way to
avoid them is, respectively:

1. redesign your app so it's not constantly deleting data. Any data
that's being deleted regularly is temp data and should not be
replicated in the first place.

2. don't create dead replicas. If you feel you must create them then
you really shouldn't be using replication at all -- it's unsuitable
for this kind of mis-use.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/