Hi

Firstly - what a relief to find an Access Community with a dedicated
Replication area. I've found it increasingly difficult to find the similar
area on the Microsoft site.

Here's my question - it would be great to get an answer because I can't work
out what the problem is......

I've set up Indirect Scheduled synchs which seem to be working fine. ReplMan
is on both client and server. Synch details are listed fine in both the
client and server log files. However, when trying to view synch details using
'View Synchronization HIstory' in Replication Manager details only appear on
the client machine and not when I am at the server.

Is this normal or have I set something up wrong? I would have thought, since
the indirect synchs are 
scheduled FROM the Server Synchronizer, the details would have been visible
from there as well?

Thanks for any help

Nigel

"Nigel Scott" <u20978@uwe> wrote in news:5ef60e07e73e6@uwe:

> I've set up Indirect Scheduled synchs which seem to be working
> fine. ReplMan is on both client and server. Synch details are
> listed fine in both the client and server log files. However, when
> trying to view synch details using 'View Synchronization HIstory'
> in Replication Manager details only appear on the client machine
> and not when I am at the server. 

The history you see will be the history for the replica you have
open. If you open a managed replica, you should see the history of
the synchs with the other synchronizer. 

> Is this normal or have I set something up wrong? I would have
> thought, since the indirect synchs are 
> scheduled FROM the Server Synchronizer, the details would have
> been visible from there as well?

The history displayed by ReplMan is the data from the exchange
history table in whatever replica you have opened in ReplMan. Open a
different replica and you will see a different history. 

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

Hi David

Glad to hear from you again - thanks for the reply. I think it underlines
that I have a problem.

I have two replicas, HubA and HubB, both managed by their own synchronizers.

I'm testing at the moment and I've set regular automatic syncs, some
initiated at the server (HubA), some at the client (HubB). All details are
shown when I "View History" at the client but neither are shown at the server,
despite the syncs being solely between these two replicas. The only details
shown server-side are for manual indirect syncs I've initiated from there.

Am I being stupid? I just thought that sync details between HubA and HubB
would be viewable by ReplMan at both HubA and HubB?

Cheers

Nigel




David W. Fenton wrote:
>> I've set up Indirect Scheduled synchs which seem to be working
>> fine. ReplMan is on both client and server. Synch details are
>> listed fine in both the client and server log files. However, when
>> trying to view synch details using 'View Synchronization HIstory'
>> in Replication Manager details only appear on the client machine
>> and not when I am at the server. 
>
>The history you see will be the history for the replica you have
>open. If you open a managed replica, you should see the history of
>the synchs with the other synchronizer. 
>
>> Is this normal or have I set something up wrong? I would have
>> thought, since the indirect synchs are 
>> scheduled FROM the Server Synchronizer, the details would have
>> been visible from there as well?
>
>The history displayed by ReplMan is the data from the exchange
>history table in whatever replica you have opened in ReplMan. Open a
>different replica and you will see a different history. 
>

-- 
Message posted via http://www.accessmonster.com

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:5f00296c27f64@uwe: 

> Glad to hear from you again - thanks for the reply. I think it
> underlines that I have a problem.
> 
> I have two replicas, HubA and HubB, both managed by their own
> synchronizers. 
> 
> I'm testing at the moment and I've set regular automatic syncs,
> some initiated at the server (HubA), some at the client (HubB).
> All details are shown when I "View History" at the client but
> neither are shown at the server, despite the syncs being solely
> between these two replicas. The only details shown server-side are
> for manual indirect syncs I've initiated from there. 
> 
> Am I being stupid? I just thought that sync details between HubA
> and HubB would be viewable by ReplMan at both HubA and HubB?

Do you have any other replicas managed by the synchronizer at HubB?
That is, could you perhaps be synching with a different replica than
you think? 

If there's only one managed replica at HubB, I don't know what the
problem would be. Is the data going through? Have you looked at the
history system table directly? 

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

Hi David

Thanks for the reply.

I'm away for the next few days so will do some checking on my return.

Thanks 

Nigel


David W. Fenton wrote:
>> Glad to hear from you again - thanks for the reply. I think it
>> underlines that I have a problem.
>[quoted text clipped - 11 lines]
>> Am I being stupid? I just thought that sync details between HubA
>> and HubB would be viewable by ReplMan at both HubA and HubB?
>
>Do you have any other replicas managed by the synchronizer at HubB?
>That is, could you perhaps be synching with a different replica than
>you think? 
>
>If there's only one managed replica at HubB, I don't know what the
>problem would be. Is the data going through? Have you looked at the
>history system table directly? 
>

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200604/1

Hi David

You are a genius!

Thanks for the help. I've just recreated the hub replicas on the server and
client and both are working fine with full synch histories at both sites. I
think the problem may have been my attempt at a replica farm. I had set up
the replica farm and it's synch schedule before doing the remote client hub.
I may have been synching with one of the replica farm reps rather than the
server hub.

Thanks once again

Nigel


Nigel Scott wrote:
>Hi David
>
>Thanks for the reply.
>
>I'm away for the next few days so will do some checking on my return.
>
>Thanks 
>
>Nigel
>
>>> Glad to hear from you again - thanks for the reply. I think it
>>> underlines that I have a problem.
>[quoted text clipped - 9 lines]
>>problem would be. Is the data going through? Have you looked at the
>>history system table directly?

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

Hi David

Sorry to reply to my own email - I'm not lonely, honest. I've just created a
replica farm and things are going fine so far.

Just a couple of questions I'd be grateful for an answer on....

1
I wonder if the previous problem was caused by me setting up the replica farm
first - so when synchs occurred the Synchronizer looked for any replica to
synch the client with, whereas now, after first setting up the synch from
ServerHub to Client the Synchronizer always synchs with SERVER_HUB.mdb?

2
Is it the same synchronzier that does both internal (SERVER_HUB to
SERVER_REPS) and external (SERVER_HUB on server to SERVER_HUB on client)
synchs.

3
Does it matter if you have local scheduled synchs between SERVER_HUB.mdb and
SERVER_REPS.mdb occurring at the same time period as synchs between the
Server and Client machines.

4
Are local synchs direct and can they be made indirect.

5
Would you advise the use of a LAN replica as well as a HUB replica or just
let LAN users connect directly to the HUB?

Best Wishes

Nigel


Nigel Scott wrote:
>Hi David
>
>You are a genius!
>
>Thanks for the help. I've just recreated the hub replicas on the server and
>client and both are working fine with full synch histories at both sites. I
>think the problem may have been my attempt at a replica farm. I had set up
>the replica farm and it's synch schedule before doing the remote client hub.
>I may have been synching with one of the replica farm reps rather than the
>server hub.
>
>Thanks once again
>
>Nigel
>
>>Hi David
>>
>[quoted text clipped - 11 lines]
>>>problem would be. Is the data going through? Have you looked at the
>>>history system table directly?

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:5fb2de04722ac@uwe: 

> Sorry to reply to my own email - I'm not lonely, honest. I've just
> created a replica farm and things are going fine so far.
> 
> Just a couple of questions I'd be grateful for an answer on....
> 
> 1
> I wonder if the previous problem was caused by me setting up the
> replica farm first - so when synchs occurred the Synchronizer
> looked for any replica to synch the client with, whereas now,
> after first setting up the synch from ServerHub to Client the
> Synchronizer always synchs with SERVER_HUB.mdb? 

I wouldn't manage the edited replica. But I would put it on a
schedule. That would mean that the edited replica would synch with
one of the replicas in the replica farm, and should be choosing the
same replica that remote replicas are synching with. Even if they
don't, two synchs should get all new data through, as long as the
replica farm is on a synch schedule whose interval is less than or
equal to the synch interval between the edited replica and the farm. 

> 2
> Is it the same synchronzier that does both internal (SERVER_HUB to
> SERVER_REPS) and external (SERVER_HUB on server to SERVER_HUB on
> client) synchs.

There can be only one synchronizer per machine.

> 3
> Does it matter if you have local scheduled synchs between
> SERVER_HUB.mdb and SERVER_REPS.mdb occurring at the same time
> period as synchs between the Server and Client machines.

Direct or indirect, I can't see that it would matter.

I would always do direct synchs over a LAN connection, no matter if
I had the indirect option or not. 

> 4
> Are local synchs direct and can they be made indirect.

Not sure what you mean here. Do you mean the synchs between the
replicas in the server farm, or the synchs between replicas on
stored on the same file server? Those should all be direct, in
preference to indirect, simply because direct is more reliable (many
of the conditions that can cause an indirect synch to fail with a
mystifying error would cause a direct synch to fail
unconditionally). 

> 5
> Would you advise the use of a LAN replica as well as a HUB replica
> or just let LAN users connect directly to the HUB?

I'd never have the LAN users editing the hub. Indeed, you *can't* do
that, as if you do, then the remote users will do a direct synch and
not indirect, since the replica that LAN users edit has to be in a
public share. Any replica that is in a public share can't reliably
be forced to synch indirect. 

The minimum replica configuration for indirect synch with LAN
editing is: 

REMOTE MACHINE:

- Edited replica

SERVER

- Hub replica
- Production replica for LAN users

I would say that any situation where there is more than one user
editing simultaneously should not be happening in a replica that is
serving as a synch hub (with scheduled synchs). The reason is that
having multiple users editing the hub replica increases the chance
of edits being in process while a synch occurs, which can cause the
synch to fail. It can also corrupt memo fields if they are being
edited in bound forms. 

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

Hi David

Thanks for the reply again.

1
You said you wouldn't manage the edited replica but that you would put it on
a schedule. 
How do you schedule a synch with a replica which is not in a Synchronizers
list of managed replicas?

2
A couple of weeks ago I wrote about scheduled synchs appearing in the
Synchronization History of a Client but not the Server. I now know why this
happened. The server Synchronization History shows synchs between the Server
HUB.mdb and the Client Synchronizer. Everything was fine until I added REP1.
At that point the client started synching with REP1.mdb instead of HUB (I
presume the Server Synchronizer decides which of the managed replicas in a
farm gets synched) so there were no synchs with HUB.mdb so no items were
added to the list. 
The Client's Synchronization History shows synchs between the Client HUB.mdb
and the Server's Synchronizer. This will always add an item to the client log
since there is no replica farm on the client so there are no alternative mdbs
for the Client Synchronizer to choose.
My question here is really if I have set the replica farm up correctly. I
created replicas in Replication Manager by selecting File > New Replica and
put them in their own folder. They, along with the HUB.mdb and LAN.mdb, are
all listed under the Server Synchronizer list of managed replicas. The Server
Synchronizer has the caption SERVER (4) depicting the 4 managed replicas -
HUB/REP1/REP2/LAN. Is this how a replica farm should be set up?

Many regards David for any help

Nigel

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:60184b5dffe9f@uwe: 

> 1
> You said you wouldn't manage the edited replica but that you would
> put it on a schedule. 
> How do you schedule a synch with a replica which is not in a
> Synchronizers list of managed replicas?

The partner replica has to be managed. That is, a managed replica
can synch on a schedule with an unmanaged replica. This is the only
way I've ever set up my replica sets, with the production replica
unmanaged and the hub synch replica managed, with a scheduled synch
between the two. 

> 2
> A couple of weeks ago I wrote about scheduled synchs appearing in
> the Synchronization History of a Client but not the Server. I now
> know why this happened. The server Synchronization History shows
> synchs between the Server HUB.mdb and the Client Synchronizer.
> Everything was fine until I added REP1. At that point the client
> started synching with REP1.mdb instead of HUB (I presume the
> Server Synchronizer decides which of the managed replicas in a 
> farm gets synched) so there were no synchs with HUB.mdb so no
> items were added to the list. 

Yes. There's a KB article about this, as well as an article on
Michael Kaplan's website that explains how Jet chooses the replica
to synch with. 

It really oughtn't be an issue, though. If you have mutliple managed
replicas, you should schedule synchs between them so that they will
have identical data after each round of synchs. That way it won't
matter which replica is chosen for synchs with remote replicas. 

> The Client's Synchronization History shows synchs between the
> Client HUB.mdb and the Server's Synchronizer. This will always add
> an item to the client log since there is no replica farm on the
> client so there are no alternative mdbs for the Client
> Synchronizer to choose. My question here is really if I have set
> the replica farm up correctly. I created replicas in Replication
> Manager by selecting File > New Replica and put them in their own
> folder. They, along with the HUB.mdb and LAN.mdb, are all listed
> under the Server Synchronizer list of managed replicas. The Server
> Synchronizer has the caption SERVER (4) depicting the 4 managed
> replicas - HUB/REP1/REP2/LAN. Is this how a replica farm should be
> set up? 

With one exception -- I think you should schedule synchs between the
members of your replica farm. 

I've never used replica farms per se. I've just kept a hub replica
(managed) and a production replica (for editing) on each server.
This is the smallest possible replica farm and doesn't really get
you the full benefit of it (since if the hub replica goes bad, your
external synchs fail), but it's been good enough for the situations
I've had set up. 

However, I will note that I don't have any current clients using
indirect scheduled synch at all. Indeed, I have only one, and that
isn't on a schedule at all. This is because all my clients that need
remote editing are now using Terminal Server and all my clients with
laptops just use direct synchs when back in the office. I don't have
any clients who need the indirect replication scenario, so don't use
it any more. My last indirect replication project went offline a
couple of years ago (after many years of successful operation in the
setup I outlined above), and it was designed before Michael had
developed the concept of the replica farm. 

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

On Thu, 11 May 2006 14:52:24 GMT, "Nigel Scott via AccessMonster.com"
<u20978@uwe> wrote:

>Hi David
>
>Thanks for the reply again.
>
>1
>You said you wouldn't manage the edited replica but that you would put it on
>a schedule. 
>How do you schedule a synch with a replica which is not in a Synchronizers
>list of managed replicas?

Replication Manager shows a dotted line between the synchronizer and
the unmanaged replica. IIRC, you just right-click on the line and
choose "Schedule..." from the popup menu.


>
>2
>A couple of weeks ago I wrote about scheduled synchs appearing in the
>Synchronization History of a Client but not the Server. I now know why this
>happened. The server Synchronization History shows synchs between the Server
>HUB.mdb and the Client Synchronizer. Everything was fine until I added REP1.
>At that point the client started synching with REP1.mdb instead of HUB (I
>presume the Server Synchronizer decides which of the managed replicas in a
>farm gets synched) so there were no synchs with HUB.mdb so no items were
>added to the list. 
>The Client's Synchronization History shows synchs between the Client HUB.mdb
>and the Server's Synchronizer. This will always add an item to the client log
>since there is no replica farm on the client so there are no alternative mdbs
>for the Client Synchronizer to choose.
>My question here is really if I have set the replica farm up correctly. I
>created replicas in Replication Manager by selecting File > New Replica and
>put them in their own folder. They, along with the HUB.mdb and LAN.mdb, are
>all listed under the Server Synchronizer list of managed replicas. The Server
>Synchronizer has the caption SERVER (4) depicting the 4 managed replicas -
>HUB/REP1/REP2/LAN. Is this how a replica farm should be set up?
>
>Many regards David for any help
>
>Nigel
**********************jackmacMACdonald@telusTELUS.net
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security

Hi David

Thanks for the reply again.

The Scheduled Synchs not appearing in the 'Synchronization History' of the
Server is just a pain - it is not convenient to go to the Client to see when
synchs with the Server occurred. I know I can view the Server log files but
it is still inconvenient. There should be some GUI to view all synchs between
all members of the Server replica set and themselves/remote Clients.

Best Wishes

Nigel

David W. Fenton wrote:
>> 1
>> You said you wouldn't manage the edited replica but that you would
>> put it on a schedule. 
>> How do you schedule a synch with a replica which is not in a
>> Synchronizers list of managed replicas?
>
>The partner replica has to be managed. That is, a managed replica
>can synch on a schedule with an unmanaged replica. This is the only
>way I've ever set up my replica sets, with the production replica
>unmanaged and the hub synch replica managed, with a scheduled synch
>between the two. 
>
>> 2
>> A couple of weeks ago I wrote about scheduled synchs appearing in
>[quoted text clipped - 6 lines]
>> farm gets synched) so there were no synchs with HUB.mdb so no
>> items were added to the list. 
>
>Yes. There's a KB article about this, as well as an article on
>Michael Kaplan's website that explains how Jet chooses the replica
>to synch with. 
>
>It really oughtn't be an issue, though. If you have mutliple managed
>replicas, you should schedule synchs between them so that they will
>have identical data after each round of synchs. That way it won't
>matter which replica is chosen for synchs with remote replicas. 
>
>> The Client's Synchronization History shows synchs between the
>> Client HUB.mdb and the Server's Synchronizer. This will always add
>[quoted text clipped - 8 lines]
>> replicas - HUB/REP1/REP2/LAN. Is this how a replica farm should be
>> set up? 
>
>With one exception -- I think you should schedule synchs between the
>members of your replica farm. 
>
>I've never used replica farms per se. I've just kept a hub replica
>(managed) and a production replica (for editing) on each server.
>This is the smallest possible replica farm and doesn't really get
>you the full benefit of it (since if the hub replica goes bad, your
>external synchs fail), but it's been good enough for the situations
>I've had set up. 
>
>However, I will note that I don't have any current clients using
>indirect scheduled synch at all. Indeed, I have only one, and that
>isn't on a schedule at all. This is because all my clients that need
>remote editing are now using Terminal Server and all my clients with
>laptops just use direct synchs when back in the office. I don't have
>any clients who need the indirect replication scenario, so don't use
>it any more. My last indirect replication project went offline a
>couple of years ago (after many years of successful operation in the
>setup I outlined above), and it was designed before Michael had
>developed the concept of the replica farm. 
>

-- 
Message posted via http://www.accessmonster.com

Thanks Jack - just the answer I needed. I suppose I should have guessed but,
like so much with Access Replication, it is a brilliant and really useful
technology which has a fairly poor GUI by Microsoft standards. In some ways
the quirkiness of it reminds be of Lotus (uurgh) products.

Cheers

Nigel




jacksonmacd wrote:
>>Hi David
>>
>[quoted text clipped - 5 lines]
>>How do you schedule a synch with a replica which is not in a Synchronizers
>>list of managed replicas?
>
>Replication Manager shows a dotted line between the synchronizer and
>the unmanaged replica. IIRC, you just right-click on the line and
>choose "Schedule..." from the popup menu.
>
>>2
>>A couple of weeks ago I wrote about scheduled synchs appearing in the
>[quoted text clipped - 19 lines]
>>
>>Nigel
>**********************jackmacMACdonald@telusTELUS.net
>remove uppercase letters for true email
>http://www.geocities.com/jacksonmacd/ for info on MS Access security

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:6022d38199b09@uwe: 

> I suppose I should have guessed but,
> like so much with Access Replication, it is a brilliant and really
> useful technology which has a fairly poor GUI by Microsoft
> standards. In some ways the quirkiness of it reminds be of Lotus
> (uurgh) products. 

The ReplMan UI is one of the worst ever produced by MS.

But it *is* discoverable. You can right click on things and get
information about them. 

And I believe that if you read the ReplMan help file it would have
told you how to set up a schedule. 

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

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:6022c84db45af@uwe: 

> The Scheduled Synchs not appearing in the 'Synchronization
> History' of the Server is just a pain - it is not convenient to go
> to the Client to see when synchs with the Server occurred. I know
> I can view the Server log files but it is still inconvenient.
> There should be some GUI to view all synchs between all members of
> the Server replica set and themselves/remote Clients. 

I'm not sure I understand what the problem is. All synchs with a
particular replica or with a particular synchronizer are viewable in
the synchronization history of that particular replica. 

Now, it is the case that synchs do not produce symmetrical records
in both partner replicas, so you don't know everything that happened
in the remote replica, but it's enough to tell you when it happened
and how it changed the replica you're viewing. 

Are you sure you're just not scrolling up the dropdown for the
synchronization history choice for your synchronizer to see all
synchs? 

Sounds to me like you need to spend some time investigating all the
features of ReplMan. 

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

Here's what I understand to be the problem. Suppose you have a replica
farm with 3 managed replicas (A, B, C) all in the same replica set.
Suppose they synchronize with a remote synchronizer called Sync2.
Further suppose that you currently have B opened in the RM and are
looking at the sync history, and it shows that *no* syncs have
occurred with Sync2. What can you conclude?... nothing...  You must
open either A or C to ensure that you've looked for all the possible
syncs that may have occurred. I think that's the problem you were
referring to.

AFAIK - each replica retains only the sync history between itself any
any other replica. It does *not* retain the sync history between its
"parent" farm and the other replicas.

What's the solution? 
1) Know which replica in the farm that Access uses for its "base
replica", and always open it into RM. *That's* the one that will be
used as the first choice when sync'ing. See
http://support.microsoft.com/kb/q173002/

2) (kludge) create a frontend that links to the replication history
table in each replica in the replica farm and create a UNION query
that displays all the synchronization history records.



On Fri, 12 May 2006 10:53:36 GMT, "Nigel Scott via AccessMonster.com"
<u20978@uwe> wrote:

>Hi David
>
>Thanks for the reply again.
>
>The Scheduled Synchs not appearing in the 'Synchronization History' of the
>Server is just a pain - it is not convenient to go to the Client to see when
>synchs with the Server occurred. I know I can view the Server log files but
>it is still inconvenient. There should be some GUI to view all synchs between
>all members of the Server replica set and themselves/remote Clients.
>
>Best Wishes
>
>Nigel
>
>David W. Fenton wrote:
>>> 1
>>> You said you wouldn't manage the edited replica but that you would
>>> put it on a schedule. 
>>> How do you schedule a synch with a replica which is not in a
>>> Synchronizers list of managed replicas?
>>
>>The partner replica has to be managed. That is, a managed replica
>>can synch on a schedule with an unmanaged replica. This is the only
>>way I've ever set up my replica sets, with the production replica
>>unmanaged and the hub synch replica managed, with a scheduled synch
>>between the two. 
>>
>>> 2
>>> A couple of weeks ago I wrote about scheduled synchs appearing in
>>[quoted text clipped - 6 lines]
>>> farm gets synched) so there were no synchs with HUB.mdb so no
>>> items were added to the list. 
>>
>>Yes. There's a KB article about this, as well as an article on
>>Michael Kaplan's website that explains how Jet chooses the replica
>>to synch with. 
>>
>>It really oughtn't be an issue, though. If you have mutliple managed
>>replicas, you should schedule synchs between them so that they will
>>have identical data after each round of synchs. That way it won't
>>matter which replica is chosen for synchs with remote replicas. 
>>
>>> The Client's Synchronization History shows synchs between the
>>> Client HUB.mdb and the Server's Synchronizer. This will always add
>>[quoted text clipped - 8 lines]
>>> replicas - HUB/REP1/REP2/LAN. Is this how a replica farm should be
>>> set up? 
>>
>>With one exception -- I think you should schedule synchs between the
>>members of your replica farm. 
>>
>>I've never used replica farms per se. I've just kept a hub replica
>>(managed) and a production replica (for editing) on each server.
>>This is the smallest possible replica farm and doesn't really get
>>you the full benefit of it (since if the hub replica goes bad, your
>>external synchs fail), but it's been good enough for the situations
>>I've had set up. 
>>
>>However, I will note that I don't have any current clients using
>>indirect scheduled synch at all. Indeed, I have only one, and that
>>isn't on a schedule at all. This is because all my clients that need
>>remote editing are now using Terminal Server and all my clients with
>>laptops just use direct synchs when back in the office. I don't have
>>any clients who need the indirect replication scenario, so don't use
>>it any more. My last indirect replication project went offline a
>>couple of years ago (after many years of successful operation in the
>>setup I outlined above), and it was designed before Michael had
>>developed the concept of the replica farm. 
>>
**********************jackmacMACdonald@telusTELUS.net
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security

jacksonmacd  wrote in
news:lppb6213cmvoskm7kun2ut2uhudh37dcug@4ax.com: 

> AFAIK - each replica retains only the sync history between itself
> any any other replica.

Not precisely correct: between that replica and any other replicas
*or synchronizers*. 

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

Hi Jack

Thanks once again.

My problem was exactly as you said. I was simply viewing the default ReplMan
view of my topology. This used a managed replica which was not the base
replica. Selecting File > Managed Replicas > basereplicaname.mdb loads the
base replica's version of the ReplMan map which does have all the synch
history information.

Thanks again

Nigel



jacksonmacd wrote:
>Here's what I understand to be the problem. Suppose you have a replica
>farm with 3 managed replicas (A, B, C) all in the same replica set.
>Suppose they synchronize with a remote synchronizer called Sync2.
>Further suppose that you currently have B opened in the RM and are
>looking at the sync history, and it shows that *no* syncs have
>occurred with Sync2. What can you conclude?... nothing...  You must
>open either A or C to ensure that you've looked for all the possible
>syncs that may have occurred. I think that's the problem you were
>referring to.
>
>AFAIK - each replica retains only the sync history between itself any
>any other replica. It does *not* retain the sync history between its
>"parent" farm and the other replicas.
>
>What's the solution? 
>1) Know which replica in the farm that Access uses for its "base
>replica", and always open it into RM. *That's* the one that will be
>used as the first choice when sync'ing. See
>http://support.microsoft.com/kb/q173002/
>
>2) (kludge) create a frontend that links to the replication history
>table in each replica in the replica farm and create a UNION query
>that displays all the synchronization history records.
>
>>Hi David
>>
>[quoted text clipped - 63 lines]
>>>setup I outlined above), and it was designed before Michael had
>>>developed the concept of the replica farm. 
>
>**********************jackmacMACdonald@telusTELUS.net
>remove uppercase letters for true email
>http://www.geocities.com/jacksonmacd/ for info on MS Access security

-- 
Message posted via http://www.accessmonster.com

Hi David

Everything seems to be working fine now thanks.

How do you allow your laptop users to synch back at the office. For example,
do you use DAO such as db.synchronize or give them access to the Access UI?

Nigel



David W. Fenton wrote:
>> 1
>> You said you wouldn't manage the edited replica but that you would
>> put it on a schedule. 
>> How do you schedule a synch with a replica which is not in a
>> Synchronizers list of managed replicas?
>
>The partner replica has to be managed. That is, a managed replica
>can synch on a schedule with an unmanaged replica. This is the only
>way I've ever set up my replica sets, with the production replica
>unmanaged and the hub synch replica managed, with a scheduled synch
>between the two. 
>
>> 2
>> A couple of weeks ago I wrote about scheduled synchs appearing in
>[quoted text clipped - 6 lines]
>> farm gets synched) so there were no synchs with HUB.mdb so no
>> items were added to the list. 
>
>Yes. There's a KB article about this, as well as an article on
>Michael Kaplan's website that explains how Jet chooses the replica
>to synch with. 
>
>It really oughtn't be an issue, though. If you have mutliple managed
>replicas, you should schedule synchs between them so that they will
>have identical data after each round of synchs. That way it won't
>matter which replica is chosen for synchs with remote replicas. 
>
>> The Client's Synchronization History shows synchs between the
>> Client HUB.mdb and the Server's Synchronizer. This will always add
>[quoted text clipped - 8 lines]
>> replicas - HUB/REP1/REP2/LAN. Is this how a replica farm should be
>> set up? 
>
>With one exception -- I think you should schedule synchs between the
>members of your replica farm. 
>
>I've never used replica farms per se. I've just kept a hub replica
>(managed) and a production replica (for editing) on each server.
>This is the smallest possible replica farm and doesn't really get
>you the full benefit of it (since if the hub replica goes bad, your
>external synchs fail), but it's been good enough for the situations
>I've had set up. 
>
>However, I will note that I don't have any current clients using
>indirect scheduled synch at all. Indeed, I have only one, and that
>isn't on a schedule at all. This is because all my clients that need
>remote editing are now using Terminal Server and all my clients with
>laptops just use direct synchs when back in the office. I don't have
>any clients who need the indirect replication scenario, so don't use
>it any more. My last indirect replication project went offline a
>couple of years ago (after many years of successful operation in the
>setup I outlined above), and it was designed before Michael had
>developed the concept of the replica farm. 
>

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

Hi David

Just a couple of questions...

1  How do you allow your laptop users to perform the direct synch back in the
office - do you use DAO (db.synchronize, etc) behind a command button or do
you let them access the Access UI?

2  The synchronizer log file on both the client (a desktop pc acting as a
server at a remote site) and server is recording attempts at synchs every
minute! Is this normal? On the server I have set up a replica farm with
managed hourly direct synchs, an unmanaged hourly direct synch to the LAN
backend and a managed daily synch to the CLIENT hub.
One possible cause of this could be that I've set up a task on the server
which daily runs a batch file to load Mstran40.exe. This is to ensure the
synchronizer is loaded whenver the server starts no matter what user id is
used to start the server.

Any help appreciated. With Replication I feel like Mulder - ever week I feel
I've finally nailed the issue then, just as I almost congratulate myself,
there's a whole new mystery which puts me back at square one again.

Nigel

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:607a0c25c4e94@uwe: 

> How do you allow your laptop users to synch back at the office.
> For example, do you use DAO such as db.synchronize or give them
> access to the Access UI? 

Depends on the users. I used to just have them use the Access UI,
but that requires opening the back end, so lately I've been creating
a UI for them that does all the work. 

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

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:607c7666b98bc@uwe: 

> 1  How do you allow your laptop users to perform the direct synch
> back in the office - do you use DAO (db.synchronize, etc) behind a
> command button or do you let them access the Access UI?

Answered in my other post.

> 2  The synchronizer log file on both the client (a desktop pc
> acting as a server at a remote site) and server is recording
> attempts at synchs every minute! Is this normal? On the server I
> have set up a replica farm with managed hourly direct synchs, an
> unmanaged hourly direct synch to the LAN backend and a managed
> daily synch to the CLIENT hub. 

I'm not sure. I've never seen that. I've also never set scheduled
synchs at that short a period. 

> One possible cause of this could be that I've set up a task on the
> server which daily runs a batch file to load Mstran40.exe. This is
> to ensure the synchronizer is loaded whenver the server starts no
> matter what user id is used to start the server.

Hmm. All you really need to do is drop a shortcut to Mstran40.exe
into the STARTUP folder of the ALL USERS profile under C:\Documents
and Settings. 

Your batch file shouldn't have an effect on the synchs, as it can't
initiate a new instance of the synchronizer if it's already running,
and wouldn't be trying to do so, anyway, as it should be executing
only on startup. Of course, you don't say exactly how you're running
the batch file, so perhaps it is getting executed twice, or when the
synchronizer is already running, but it shouldn't matter, in any
case. That is, I don't think it's the cause of your log entries. 

> Any help appreciated. With Replication I feel like Mulder - ever
> week I feel I've finally nailed the issue then, just as I almost
> congratulate myself, there's a whole new mystery which puts me
> back at square one again. 

We've all been there. It's not going to get better, either, as MS is
basically abandoning Jet replication with the next version of
Access. 

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

Hi David

I've removed the replica farms and everything is synchronizing when it should.
I didn't block-fill all the schedule blocks - I've no idea why it was
synching every minute - it was only supposed to be doing it every hour.

Anyway, it is working now.

As regards the direct laptop sycnchs you do - have you had any problems
direct synching with the live backend when other LAN users could be making
live edits?

Cheers

Nigel



David W. Fenton wrote:
>> 1  How do you allow your laptop users to perform the direct synch
>> back in the office - do you use DAO (db.synchronize, etc) behind a
>> command button or do you let them access the Access UI?
>
>Answered in my other post.
>
>> 2  The synchronizer log file on both the client (a desktop pc
>> acting as a server at a remote site) and server is recording
>> attempts at synchs every minute! Is this normal? On the server I
>> have set up a replica farm with managed hourly direct synchs, an
>> unmanaged hourly direct synch to the LAN backend and a managed
>> daily synch to the CLIENT hub. 
>
>I'm not sure. I've never seen that. I've also never set scheduled
>synchs at that short a period. 
>
>> One possible cause of this could be that I've set up a task on the
>> server which daily runs a batch file to load Mstran40.exe. This is
>> to ensure the synchronizer is loaded whenver the server starts no
>> matter what user id is used to start the server.
>
>Hmm. All you really need to do is drop a shortcut to Mstran40.exe
>into the STARTUP folder of the ALL USERS profile under C:\Documents
>and Settings. 
>
>Your batch file shouldn't have an effect on the synchs, as it can't
>initiate a new instance of the synchronizer if it's already running,
>and wouldn't be trying to do so, anyway, as it should be executing
>only on startup. Of course, you don't say exactly how you're running
>the batch file, so perhaps it is getting executed twice, or when the
>synchronizer is already running, but it shouldn't matter, in any
>case. That is, I don't think it's the cause of your log entries. 
>
>> Any help appreciated. With Replication I feel like Mulder - ever
>> week I feel I've finally nailed the issue then, just as I almost
>> congratulate myself, there's a whole new mystery which puts me
>> back at square one again. 
>
>We've all been there. It's not going to get better, either, as MS is
>basically abandoning Jet replication with the next version of
>Access. 
>

-- 
Message posted via http://www.accessmonster.com

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:60b81c5666f47@uwe: 

> As regards the direct laptop sycnchs you do - have you had any
> problems direct synching with the live backend when other LAN
> users could be making live edits?

Yes, for memo fields. Also when trying to synch design changes.

For memo fields, make them unbound. This is easy by putting in the
form's record source, and loading the data into an unbound textbox
in the OnCurrent event of the form, and writing the value back to
the recordsource in the AfterUpdate event of the unbound textbox. 

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

Hi David

I've yet to make design changes and ripple them out to all the replicas. I
thought you made the design change to the DesignMaster then synched them out
to the replicas as soon as possible. If it is a small site I'd be tempted to
simply recreate the replicas.

Nigel


David W. Fenton wrote:
>> As regards the direct laptop sycnchs you do - have you had any
>> problems direct synching with the live backend when other LAN
>> users could be making live edits?
>
>Yes, for memo fields. Also when trying to synch design changes.
>
>For memo fields, make them unbound. This is easy by putting in the
>form's record source, and loading the data into an unbound textbox
>in the OnCurrent event of the form, and writing the value back to
>the recordsource in the AfterUpdate event of the unbound textbox. 
>

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:60c4e66a2518c@uwe: 

> I've yet to make design changes and ripple them out to all the
> replicas. I thought you made the design change to the DesignMaster
> then synched them out to the replicas as soon as possible. 

Yes, but if that synch happens while a replica is being edited, the
change won't be propagated, since structural changes to tables can't
be applied while someone has the table open. It doesn't matter if
the changes go direct from the DM to the replica, or through an
intervening replica -- the result in a replica that is being edited
at the time the synch of the design change is attempted will be a
failure of the synch. 

> . . . If it is a small site I'd be tempted to
> simply recreate the replicas.

No, you can't ever do that because it creates dead replicas, which
can lead to replication errors and possibly complete corruption and
loss of the replica set. 

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

Hi David

So if I make sure all users are off the system then there should be no
problems with rippling out any DM changes?

Nigel



David W. Fenton wrote:
>> I've yet to make design changes and ripple them out to all the
>> replicas. I thought you made the design change to the DesignMaster
>> then synched them out to the replicas as soon as possible. 
>
>Yes, but if that synch happens while a replica is being edited, the
>change won't be propagated, since structural changes to tables can't
>be applied while someone has the table open. It doesn't matter if
>the changes go direct from the DM to the replica, or through an
>intervening replica -- the result in a replica that is being edited
>at the time the synch of the design change is attempted will be a
>failure of the synch. 
>
>> . . . If it is a small site I'd be tempted to
>> simply recreate the replicas.
>
>No, you can't ever do that because it creates dead replicas, which
>can lead to replication errors and possibly complete corruption and
>loss of the replica set. 
>

-- 
Message posted via http://www.accessmonster.com

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:60c7ae008428a@uwe: 

> So if I make sure all users are off the system then there should
> be no problems with rippling out any DM changes?

As long as the changes are valid and don't involve any changes to
validation rules or referential integrity that would prohibit them
from being propagated. 

I always try to break down design changes that alter RI and
validation rules into small steps with a synch between each steup,
instead of doing them all at once and hoping Jet puts them through
in the right order. It's the same any time you're doing something
like changing the foreign key on child records. You want to change
the foreign key, synch, then delete the parent record and synch
again, rather than doing both, because if CASCADE DELETES is on, you
run the risk of deleting the child records instead. 

In general, design changes should be avoided in a production app,
unless absolutely necessary. What this means is that you have to
settle the schema before the app goes into production, and if
necessary schema changes become apparent later, you have to be very
careful about rolling them out. The key is making plenty of backups
of the affected data and doing your changes as incrementally as
possible. 

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

Hi David

Thanks for the DM change advice.

I've identified the cause of the 'Synch every minute despite not setting this
option' problem. The SERVER_DROPBOX folder had slightly dodgy permissions and
would not allow deletes. This seemed to be causing a massive build-up of temp
files - over a thousand in a day - all with the prefix rep. For example,
rep101.msg (4kb), rep101.mdb (168kb), rep101.ldb (4kb), rep101.tmp (0kb). The
network administrator said this was due to permissions not filtering down
properly. He manually set the permissions to Modify for all users and the
problem was solved.

A few questions:

1  As regards my suggestion to simply recreate the replicas when changing DM
structure I meant deleting all replicas (from both the ReplMan map and the
hard-drive) then creating new replicas using File > New Replica. The new
replicas would have the same name but since the originals are no longer there
is that a problem?

2  To roll out replicas to a remote office pc (which will act as the remote
office server) I make a dos copy of HUB.mdb (also called HUB.mdb) and put it
on the remote pc. I then open ReplMan and manage this copy. This gives the
copy it's own id. I then synchronize with the SERVER so both synchronizers
become aware of both replicas. Is this ok? I've read that both this method
and using the ReplMan > File > More Replica are both fine.

3  To put a replica on a laptop I connect the laptop to the server, open the
server's BE.mdb and then create a replica using the Access menus. Is this how
you would do it?

Thanks for the help. Have a nice weekend.

Nigel




David W. Fenton wrote:
>> So if I make sure all users are off the system then there should
>> be no problems with rippling out any DM changes?
>
>As long as the changes are valid and don't involve any changes to
>validation rules or referential integrity that would prohibit them
>from being propagated. 
>
>I always try to break down design changes that alter RI and
>validation rules into small steps with a synch between each steup,
>instead of doing them all at once and hoping Jet puts them through
>in the right order. It's the same any time you're doing something
>like changing the foreign key on child records. You want to change
>the foreign key, synch, then delete the parent record and synch
>again, rather than doing both, because if CASCADE DELETES is on, you
>run the risk of deleting the child records instead. 
>
>In general, design changes should be avoided in a production app,
>unless absolutely necessary. What this means is that you have to
>settle the schema before the app goes into production, and if
>necessary schema changes become apparent later, you have to be very
>careful about rolling them out. The key is making plenty of backups
>of the affected data and doing your changes as incrementally as
>possible. 
>

-- 
Message posted via http://www.accessmonster.com

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:60d2459a1e349@uwe: 

> 1  As regards my suggestion to simply recreate the replicas when
> changing DM structure I meant deleting all replicas (from both the
> ReplMan map and the hard-drive) then creating new replicas using
> File > New Replica. The new replicas would have the same name but
> since the originals are no longer there is that a problem?

If you're keeping the same DM, then, yes, it would be a problem,
since the DM still has a record of the replicas you created. 

I suggest you search the archives of this newsgroup on Google Groups
for the phrase "dead replicas" because that will explain to you why
this is a bad idea. Basically, once a replica is in place, it has to
remain in that place and not be copied, moved, deleted, emailed or
overwritten by a file of the same name. 

> 2  To roll out replicas to a remote office pc (which will act as
> the remote office server) I make a dos copy of HUB.mdb (also
> called HUB.mdb) and put it on the remote pc. I then open ReplMan
> and manage this copy. This gives the copy it's own id. I then
> synchronize with the SERVER so both synchronizers become aware of
> both replicas. Is this ok? I've read that both this method and
> using the ReplMan > File > More Replica are both fine. 

It's OK to use a copy of a replica to initialize a setup with the
first replica. Once it's in place, then it has to stay there. 

> 3  To put a replica on a laptop I connect the laptop to the
> server, open the server's BE.mdb and then create a replica using
> the Access menus. Is this how you would do it?

You could do that or copy it just like with the hub. But that is the
only situation where a file system copy is OK, because it creates a
new replica ID as soon as the file is opened in its new location. 

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

Thanks, once again, David for your help and advice.

Nigel


David W. Fenton wrote:
>> 1  As regards my suggestion to simply recreate the replicas when
>> changing DM structure I meant deleting all replicas (from both the
>> ReplMan map and the hard-drive) then creating new replicas using
>> File > New Replica. The new replicas would have the same name but
>> since the originals are no longer there is that a problem?
>
>If you're keeping the same DM, then, yes, it would be a problem,
>since the DM still has a record of the replicas you created. 
>
>I suggest you search the archives of this newsgroup on Google Groups
>for the phrase "dead replicas" because that will explain to you why
>this is a bad idea. Basically, once a replica is in place, it has to
>remain in that place and not be copied, moved, deleted, emailed or
>overwritten by a file of the same name. 
>
>> 2  To roll out replicas to a remote office pc (which will act as
>> the remote office server) I make a dos copy of HUB.mdb (also
>[quoted text clipped - 3 lines]
>> both replicas. Is this ok? I've read that both this method and
>> using the ReplMan > File > More Replica are both fine. 
>
>It's OK to use a copy of a replica to initialize a setup with the
>first replica. Once it's in place, then it has to stay there. 
>
>> 3  To put a replica on a laptop I connect the laptop to the
>> server, open the server's BE.mdb and then create a replica using
>> the Access menus. Is this how you would do it?
>
>You could do that or copy it just like with the hub. But that is the
>only situation where a file system copy is OK, because it creates a
>new replica ID as soon as the file is opened in its new location. 
>

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

Hi David

Two questions I'd appreciate your opinion on...

1  I copy the HUB replica into a folder on the server. I then copy this out
to be the remote HUB. I appreciate that once the remote HUB is
opened/initialized it can never be moved. However, why do you say the copy on
the server must never be there?
2  Making a copy of the managed server HUB into the remote HUB on several pcs
means each HUB has the same file name. Is this ok or would it be better for
each remote HUB to have it's own name?

Cheers

Nigel


David W. Fenton wrote:
>> 1  As regards my suggestion to simply recreate the replicas when
>> changing DM structure I meant deleting all replicas (from both the
>> ReplMan map and the hard-drive) then creating new replicas using
>> File > New Replica. The new replicas would have the same name but
>> since the originals are no longer there is that a problem?
>
>If you're keeping the same DM, then, yes, it would be a problem,
>since the DM still has a record of the replicas you created. 
>
>I suggest you search the archives of this newsgroup on Google Groups
>for the phrase "dead replicas" because that will explain to you why
>this is a bad idea. Basically, once a replica is in place, it has to
>remain in that place and not be copied, moved, deleted, emailed or
>overwritten by a file of the same name. 
>
>> 2  To roll out replicas to a remote office pc (which will act as
>> the remote office server) I make a dos copy of HUB.mdb (also
>[quoted text clipped - 3 lines]
>> both replicas. Is this ok? I've read that both this method and
>> using the ReplMan > File > More Replica are both fine. 
>
>It's OK to use a copy of a replica to initialize a setup with the
>first replica. Once it's in place, then it has to stay there. 
>
>> 3  To put a replica on a laptop I connect the laptop to the
>> server, open the server's BE.mdb and then create a replica using
>> the Access menus. Is this how you would do it?
>
>You could do that or copy it just like with the hub. But that is the
>only situation where a file system copy is OK, because it creates a
>new replica ID as soon as the file is opened in its new location. 
>

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200605/1

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:61147a01da17f@uwe: 

> Two questions I'd appreciate your opinion on...
> 
> 1  I copy the HUB replica into a folder on the server. I then copy
> this out to be the remote HUB. I appreciate that once the remote
> HUB is opened/initialized it can never be moved. However, why do
> you say the copy on the server must never be there?

Did I say that? I don't see that in anything I wrote. What is it
that you're interpreting to mean that? 

> 2  Making a copy of the managed server HUB into the remote HUB on
> several pcs means each HUB has the same file name. Is this ok or
> would it be better for each remote HUB to have it's own name?

I always make all the replicas have the same filename, but since the
proper place to store user data is in the user's profile, they would
not have the same *path*. And, given that each machine must have a
different name, the machine name place the local path means that
each is unique. 

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

Hi David

Regarding my question "However, why do you say the copy on the server must
never be there?" and your response "Did I say that? I don't see that in
anything I wrote. What is it that you're interpreting to mean that?".
I was reading your first comment ("Basically, once a replica is in place, it
has to remain in that place and not be copied, moved, deleted, emailed or
overwritten by a file of the same name") and combining that with another
comment from KB272414: MOD2000: How to Distribute a Replica Set for Indirect
Synchronization which says... "Move the copy of the replica to the secondary
computer. NOTE: It is important to move the replica rather than copy it to
the secondary computer. A copy of the replica should not remain on the
primary computer." However, in the Access 2000 Replication FAQ from Microsoft
("Frequently Asked Questions About Microsoft Access 2000 Replication" written
by Michael Kaplan, Mary Chipman, Paul Litwin, Steve Thompson, and John Blaine)
they do not say you have to move the copy of the replica. I think your
comment refers to replicas once they are initialized, and I misread it.

In the FAQ article they recommend using unbound forms to minimize replication
data errors, since bound forms could hold a table open, blocking successful
replication. Have you had any problems using bound forms, or are all your
forms unbound?

Cheers

Nigel

-- 
Message posted via http://www.accessmonster.com

"Nigel Scott via AccessMonster.com" <u20978@uwe> wrote in
news:61299913faf7f@uwe: 

> Regarding my question "However, why do you say the copy on the
> server must never be there?" and your response "Did I say that? I
> don't see that in anything I wrote. What is it that you're
> interpreting to mean that?". I was reading your first comment
> ("Basically, once a replica is in place, it has to remain in that
> place and not be copied, moved, deleted, emailed or overwritten by
> a file of the same name") and combining that with another comment
> from KB272414: MOD2000: How to Distribute a Replica Set for
> Indirect Synchronization which says... "Move the copy of the
> replica to the secondary computer. NOTE: It is important to move
> the replica rather than copy it to the secondary computer. A copy
> of the replica should not remain on the primary computer."
> However, in the Access 2000 Replication FAQ from Microsoft 
> ("Frequently Asked Questions About Microsoft Access 2000
> Replication" written by Michael Kaplan, Mary Chipman, Paul Litwin,
> Steve Thompson, and John Blaine) they do not say you have to move
> the copy of the replica. I think your comment refers to replicas
> once they are initialized, and I misread it. 

OK, here's where the confusion is:

There is a MOVE REPLICA command in Jet that moves the replica from
one place to another and updates the replication tables to reflect
that change of location for that particular replica. The most common
place to see this command is in the menus of Replication Manager,
but it's also available programmatically through the TSI
Synchronizer and through JRO. 

Don't confuse the instruction to MOVE REPLICAS with a file system
move -- it's not at all the same thing. 

If you MOVE a replica, it won't exist in its original location.

Now, I don't understand why you'd ask the question, though. There's
no reason to create extra replicas on the server at all. Just copy
the main replica from the server to the destination locations, using
the file system. Once those replicas are opened in place, they'll
get assigned their new replica ID, but still retain all the
information about the replica set that the replica they were copied
from had in it. 

> In the FAQ article they recommend using unbound forms to minimize
> replication data errors, since bound forms could hold a table
> open, blocking successful replication. Have you had any problems
> using bound forms, or are all your forms unbound?

I don't use unbound forms very often. In replication, the only
exception would be is that I edit memo fields in unbound textboxes,
but I update them through a bound form recordsource. 

In general, I avoid situations where replication happens at a time
when users are editing. However, if you're on a schedule, this can
sometimes be impossible. If errors develop for this reason, they
will go away as soon as you synch in a situation where the error
condition is absent, so a scheduled synch overnight will take care
of that. 

Going to all unbound forms is just ridiculous overkill, and is one
of the many things in the replication FAQ that is unreliable advice,
in my opinion. Going entirely unbound means you're losing out on the
key strengths of Access -- it's throwing out the baby with the
bathwater to avoid a problem that is only transient in the first
place. 

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

Hi David

Thanks for the information.

It is true that I don't need to create a replica copy - I could just copy the
main replica from the server to the destination locations. I just thought it
was a bit easier to put the dos HUB copy in a folder called 'Deploy' and use
that as the source for all remote HUBs. I copy from there and then open
ReplMan at the remote site and initialize it.

Cheers

Nigel

-- 
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-replication/200606/1