Replication clarification

[Sharktbbtfy]

Hi, hoping someone can help.

The situation is that an app I designed is installed on a desktop PC and six
laptops,separately, which synchronise to the desktop once a day at random
times.

I have two questions:

1) Is it advisable to not have the design master as the mothership but have
a replica on the desktop where the backend is named, e.g., replica of
be.mdb? (I'm aware of the 1000 day rule.)

2) Should the laptops be.mdb's be all named replica1 of be.mdb or should
they be named replica1, replica2, etc?

Any and all advice gratefully received.

Sharktbbtfy

[David W. Fenton]

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45******@news01.wxnz.net:

The situation is that an app I designed is installed on a desktop
PC and six laptops,separately, which synchronise to the desktop
once a day at random times.

I have two questions:

1) Is it advisable to not have the design master as the mothership
but have a replica on the desktop where the backend is named,
e.g., replica of be.mdb? (I'm aware of the 1000 day rule.)

Your DM is more important than any other replica in the replica set,
because it's the only one that you can make design changes in. So,
you don't want it exposed to the daily danger of corruption or
damage that comes with having multiple users editing it, and many
users synchronizing with it.

As to names, I give all replicas exactly the same name, and let
their location denote their function. So, the DM could be data.mdb
but would be stored in a DesignMaster folder.

I would also recommending not having laptop users synch with the LAN
production replica, but have a synchronization hub that is synched
on a schedule with the production hub.

2) Should the laptops be.mdb's be all named replica1 of be.mdb or
should they be named replica1, replica2, etc?

Why do you need to give them different names? Where are you looking
at a list of replicas that you can't tell which one is which?

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

[Sharktbbtfy]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45******@news01.wxnz.net:

>The situation is that an app I designed is installed on a desktop
PC and six laptops,separately, which synchronise to the desktop
once a day at random times.

I have two questions:

1) Is it advisable to not have the design master as the mothership
but have a replica on the desktop where the backend is named,
e.g., replica of be.mdb? (I'm aware of the 1000 day rule.)

Your DM is more important than any other replica in the replica set,
because it's the only one that you can make design changes in. So,
you don't want it exposed to the daily danger of corruption or
damage that comes with having multiple users editing it, and many
users synchronizing with it.

The design master would only be the front end, wouldn't it? The master on
the desktop PC would backup the backend daily to another place.

>
As to names, I give all replicas exactly the same name, and let
their location denote their function. So, the DM could be data.mdb
but would be stored in a DesignMaster folder.

I have the front ends in a folder, e.g. C:\Program Files\DBM with the
backends in a folder C:\Program Files\Common Files\DBM on the desktop PC
and the laptops.

>
I would also recommending not having laptop users synch with the LAN
production replica, but have a synchronization hub that is synched
on a schedule with the production hub.

Not quite sure what this means. The laptops are out all day and synchro when
they come back to base. I had planned to have one master on the desktop PC
(not the design master) and have the laptops synchro to that. The master
would also be used for editing/adding records,etc.

>

>2) Should the laptops be.mdb's be all named replica1 of be.mdb or
should they be named replica1, replica2, etc?

Why do you need to give them different names? Where are you looking
at a list of replicas that you can't tell which one is which?

Just covering my bases. I wasn't sure what would happen if they attempted to
synchro two laptops at the same time.

>

Greatly, appreciate the help and as you can probably tell I'm newish to
replication/synchronisation.

--
Sharktbbtfy

[David W. Fenton]

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45********@news01.wxnz.net:

>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

>"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45******@news01.wxnz.net:

>>The situation is that an app I designed is installed on a
desktop PC and six laptops,separately, which synchronise to the
desktop once a day at random times.

I have two questions:

1) Is it advisable to not have the design master as the
mothership but have a replica on the desktop where the backend
is named, e.g., replica of be.mdb? (I'm aware of the 1000 day
rule.)

Your DM is more important than any other replica in the replica
set, because it's the only one that you can make design changes
in. So, you don't want it exposed to the daily danger of
corruption or damage that comes with having multiple users
editing it, and many users synchronizing with it.

The design master would only be the front end, wouldn't it?

Front end? Front ends should never be replicated, only back ends
(data tables only). This is because Jet replication works reliably
only with pure Jet objects (table and queries) and has problems with
Access objects (especially forms, but also reports, macros, modules,
etc.).

And no app, replicated or not, should be unsplit.

The master on
the desktop PC would backup the backend daily to another place.

What do you mean "master on the desktop PC?" There's only "master"
in a replica set. It should not be used for daily editing because
it's an essential replica, the only one in the whole replica set
that is *not* disposable.

>As to names, I give all replicas exactly the same name, and let
their location denote their function. So, the DM could be
data.mdb but would be stored in a DesignMaster folder.

I have the front ends in a folder, e.g. C:\Program Files\DBM with
the backends in a folder C:\Program Files\Common Files\DBM on the
desktop PC and the laptops.

>>
I would also recommending not having laptop users synch with the
LAN production replica, but have a synchronization hub that is
synched on a schedule with the production hub.

Not quite sure what this means. The laptops are out all day and
synchro when they come back to base. I had planned to have one
master on the desktop PC (not the design master) and have the
laptops synchro to that. The master would also be used for
editing/adding records,etc.

Ah, I see -- you're using confusing terminology. What you call
"master" is what I mean by "production editing replica" or by
"synchronization hub." If you no users connected to the LAN all the
time editing a server-based back end, then you don't have a
production replica at all.

But, yes, you want your synchs to be with anything other than the
DM, because direct synchs are the most likely to corrupt the remote
replica, and if you're synching laptops with the DM, it's the DM
that's in danger of corruption.

>>2) Should the laptops be.mdb's be all named replica1 of be.mdb
or should they be named replica1, replica2, etc?

Why do you need to give them different names? Where are you
looking at a list of replicas that you can't tell which one is
which?

Just covering my bases. I wasn't sure what would happen if they
attempted to synchro two laptops at the same time.

The laptops have different machine names, or they couldn't connect
to the LAN all at once. Each replica is identified by it's machine
name and path. The actual name doesn't matter. Unless you're naming
laptops the same thing, you have no issues here.

Greatly, appreciate the help and as you can probably tell I'm
newish to replication/synchronisation.

I would suggest that you go to my Jet Replication Wiki:

http://www.dfenton.com/DFA/Replication/

and go to the 3rd topic listed on the front page, "Resources for
learning about Jet Replication." That will give you the starting
point, and quite a bit of information.

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

[Sharktbbtfy]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45********@news01.wxnz.net:

>>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0 .1...

>>"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45******@news01.wxnz.net:

The situation is that an app I designed is installed on a
desktop PC and six laptops,separately, which synchronise to the
desktop once a day at random times.

I have two questions:

1) Is it advisable to not have the design master as the
mothership but have a replica on the desktop where the backend
is named, e.g., replica of be.mdb? (I'm aware of the 1000 day
rule.)

Your DM is more important than any other replica in the replica
set, because it's the only one that you can make design changes
in. So, you don't want it exposed to the daily danger of
corruption or damage that comes with having multiple users
editing it, and many users synchronizing with it.

The design master would only be the front end, wouldn't it?

Front end? Front ends should never be replicated, only back ends
(data tables only). This is because Jet replication works reliably
only with pure Jet objects (table and queries) and has problems with
Access objects (especially forms, but also reports, macros, modules,
etc.).

>
And no app, replicated or not, should be unsplit.

>The master on
the desktop PC would backup the backend daily to another place.

What do you mean "master on the desktop PC?" There's only "master"
in a replica set. It should not be used for daily editing because
it's an essential replica, the only one in the whole replica set
that is *not* disposable.

>>As to names, I give all replicas exactly the same name, and let
their location denote their function. So, the DM could be
data.mdb but would be stored in a DesignMaster folder.

I have the front ends in a folder, e.g. C:\Program Files\DBM with
the backends in a folder C:\Program Files\Common Files\DBM on the
desktop PC and the laptops.

>>>
I would also recommending not having laptop users synch with the
LAN production replica, but have a synchronization hub that is
synched on a schedule with the production hub.

Not quite sure what this means. The laptops are out all day and
synchro when they come back to base. I had planned to have one
master on the desktop PC (not the design master) and have the
laptops synchro to that. The master would also be used for
editing/adding records,etc.

Ah, I see -- you're using confusing terminology. What you call
"master" is what I mean by "production editing replica" or by
"synchronization hub." If you no users connected to the LAN all the
time editing a server-based back end, then you don't have a
production replica at all.

But, yes, you want your synchs to be with anything other than the
DM, because direct synchs are the most likely to corrupt the remote
replica, and if you're synching laptops with the DM, it's the DM
that's in danger of corruption.

>>>2) Should the laptops be.mdb's be all named replica1 of be.mdb
or should they be named replica1, replica2, etc?

Why do you need to give them different names? Where are you
looking at a list of replicas that you can't tell which one is
which?

Just covering my bases. I wasn't sure what would happen if they
attempted to synchro two laptops at the same time.

The laptops have different machine names, or they couldn't connect
to the LAN all at once. Each replica is identified by it's machine
name and path. The actual name doesn't matter. Unless you're naming
laptops the same thing, you have no issues here.

>Greatly, appreciate the help and as you can probably tell I'm
newish to replication/synchronisation.

I would suggest that you go to my Jet Replication Wiki:

http://www.dfenton.com/DFA/Replication/

and go to the 3rd topic listed on the front page, "Resources for
learning about Jet Replication." That will give you the starting
point, and quite a bit of information.

So, the upshot is that the design master will be separate and synchroed
within every 1000 days.

The PC master (production editing replica / synchronization hub) will
synchro to the laptops, the backend being replica of be.mdb.

All of the laptop backends will all be replica1 of be.mdb.

I will read "http://www.dfenton.com/DFA/Replication/

and go to the 3rd topic listed on the front page, "Resources for
learning about Jet Replication." That will give you the starting
point, and quite a bit of information.

Thanks very much for all your help.

Cheers,
--
Sharktbbtfy

[David W. Fenton]

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45******@news01.wxnz.net:

So, the upshot is that the design master will be separate and
synchroed within every 1000 days.

Yes.

The PC master (production editing replica / synchronization hub)
will synchro to the laptops, the backend being replica of be.mdb.

For your situation, this is OK, as you don't have any LAN users
sharing the one you call the "master." But if you had a server and a
LAN with several people connected to the LAN and sharing a back end,
and you then wanted to synch laptop users, you'd want to have
separate replicas for the production replica and the synch hub.

All of the laptop backends will all be replica1 of be.mdb.

That's your choice. I just think it's easier to have everything the
same name.

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

[Sharktbbtfy]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45******@news01.wxnz.net:

>So, the upshot is that the design master will be separate and
synchroed within every 1000 days.

Yes.

>The PC master (production editing replica / synchronization hub)
will synchro to the laptops, the backend being replica of be.mdb.

For your situation, this is OK, as you don't have any LAN users
sharing the one you call the "master." But if you had a server and a
LAN with several people connected to the LAN and sharing a back end,
and you then wanted to synch laptop users, you'd want to have
separate replicas for the production replica and the synch hub.

>All of the laptop backends will all be replica1 of be.mdb.

That's your choice. I just think it's easier to have everything the
same name.

Duh! Light goes on! So the laptop backends can have the same name as the PC
desktop "master" due to them having different paths.

Thanks for everything mate.

Cheers,
--
Sharktbbtfy

[David W. Fenton]

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45********@news01.wxnz.net:

Duh! Light goes on! So the laptop backends can have the same name
as the PC desktop "master" due to them having different paths.

You should spend some time examining the replication system tables.
It might give you quite a bit of information that would help you
make these kinds of decisions. That's how I learned these things,
since there sure ain't much help from Microsoft!

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

[Sharktbbtfy]

"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Sharktbbtfy" <sh****@tw.co.uktvwrote in
news:45********@news01.wxnz.net:

>Duh! Light goes on! So the laptop backends can have the same name
as the PC desktop "master" due to them having different paths.

You should spend some time examining the replication system tables.

Will do

It might give you quite a bit of information that would help you
make these kinds of decisions. That's how I learned these things,
since there sure ain't much help from Microsoft!

Again, thanks for all your help. Invaluable.
--
Sharktbbtfy