|
|
Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
I have three groups of application databases to manage, Set1, Set2, and
Set3.
Set1 contains 35 databases, Set2 has 5 databases, and Set 3 has 15
databases.
These are three distinct, unrelated database applications I hope to
implement replication with.
I have been able to set up replman to manage what I call Set1 and this works
fine.
I do not seem to be able to create another Set of databases to manage via
Replman.
Does Replman only manage one Set?
Regards.
|
|
"rg" <rg01[ at ]goodnews.net> wrote in
news:eJb5VjOzGHA.1936[ at ]TK2MSFTNGP06.phx.gbl:
[Quoted Text] > Does Replman only manage one Set?
The synchronizer can manage as many replica sets as needed.
What is preventing you from opening a different replica and managing
some of the replicas in its replica set?
ReplMan can't display more than one replica set at a time, though.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
David,
Thanks for the info.
I closed the current managed set and tried to open a new set to manage but
no matter what I try, Replman wants to have the new set be managed by the
originally creates synchronizer.
Any thoughts/direction?
Regards, Roger
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns983048A8958BFf99a49ed1d0c49c5bbb2[ at ]127.0.0.1...
[Quoted Text] > "rg" <rg01[ at ]goodnews.net> wrote in > news:eJb5VjOzGHA.1936[ at ]TK2MSFTNGP06.phx.gbl: > > > Does Replman only manage one Set? > > The synchronizer can manage as many replica sets as needed. > > What is preventing you from opening a different replica and managing > some of the replicas in its replica set? > > ReplMan can't display more than one replica set at a time, though. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
David,
Perhaps I am misunderstanding the role of the synchronizer. The three
applications I have are a Personnel (35 replicas), Banking (5 replicas), and
Chemical tracking (15 replicas).
Since I can only get 1 synchronizer to work on the workstation, do I throw
all 55 replicas into the Synchronizer and it figures out what replica goes
with what application and replicate?
Regards, Roger
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns983048A8958BFf99a49ed1d0c49c5bbb2[ at ]127.0.0.1...
[Quoted Text] > "rg" <rg01[ at ]goodnews.net> wrote in > news:eJb5VjOzGHA.1936[ at ]TK2MSFTNGP06.phx.gbl: > > > Does Replman only manage one Set? > > The synchronizer can manage as many replica sets as needed. > > What is preventing you from opening a different replica and managing > some of the replicas in its replica set? > > ReplMan can't display more than one replica set at a time, though. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"rg" <rg01[ at ]goodnews.net> wrote in
news:OeR5k2PzGHA.4576[ at ]TK2MSFTNGP06.phx.gbl:
[Quoted Text] > I closed the current managed set and tried to open a new set to
> manage but no matter what I try, Replman wants to have the new set
> be managed by the originally creates synchronizer.
What is the problem? You can only have one synchronizer per machine,
so if you're opening replication manager on the same machine, it's
going to be managed by the same synchronizer.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"rg" <rg01[ at ]goodnews.net> wrote in
news:OZYQOLQzGHA.3464[ at ]TK2MSFTNGP03.phx.gbl:
[Quoted Text] > Perhaps I am misunderstanding the role of the synchronizer. The
> three applications I have are a Personnel (35 replicas), Banking
> (5 replicas), and Chemical tracking (15 replicas).
>
> Since I can only get 1 synchronizer to work on the workstation, do
> I throw all 55 replicas into the Synchronizer and it figures out
> what replica goes with what application and replicate?
Yes. Replicas from different replica sets can't synch with each
other, so there's no danger there.
However, I would wonder why you have very many replicas managed.
Only the ones that need to be on one end of an indirect synch need
to be managed. The others don't. This would, for instance, include
the production replica that LAN users edit and all the replicas on
laptops that aren't connected all the time. If you're using indirect
replication from the laptops (i.e., they have to synch with the
mother ship over the Internet or a WAN, rather than a LAN), then
there will be a synchronizer on each laptop.
But you shouldn't be managing all the replicas in each replica set.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns983079054804f99a49ed1d0c49c5bbb2[ at ]127.0.0.1...
[Quoted Text] > "rg" <rg01[ at ]goodnews.net> wrote in
> news:OZYQOLQzGHA.3464[ at ]TK2MSFTNGP03.phx.gbl:
>
>
> However, I would wonder why you have very many replicas managed.
> Only the ones that need to be on one end of an indirect synch need
> to be managed. The others don't. This would, for instance, include
> the production replica that LAN users edit and all the replicas on
> laptops that aren't connected all the time. If you're using indirect
> replication from the laptops (i.e., they have to synch with the
> mother ship over the Internet or a WAN, rather than a LAN), then
> there will be a synchronizer on each laptop.
>
> But you shouldn't be managing all the replicas in each replica set.
>
Hi David,
Are there any significant pro's/con's by managing/using indirect sync over
LAN as opposed to direct sync's?
Thanks,
Mark
|
|
"Mark" <nospam[ at ]nospam.nospam> wrote in
news:OmMMGRVzGHA.4896[ at ]TK2MSFTNGP03.phx.gbl:
[Quoted Text] > Are there any significant pro's/con's by managing/using indirect
> sync over LAN as opposed to direct sync's?
The only one is that you have to know the exact path/name of the
target remote replica, whereas with indirect to a synchronizer, the
synchronizer picks the remote partner replica from the managed
replicas in the replica set.
Direct replication is *much* simpler to implement (basically one
line of code), and doesn't require starting and stopping the
synchronizer on the local machine. Over a LAN, I'd never use
anything else, except for some really good reason.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in
news:Xns9830D3419F5D5f99a49ed1d0c49c5bbb2[ at ]127.0.0.1:
[Quoted Text] > "Mark" <nospam[ at ]nospam.nospam> wrote in
> news:OmMMGRVzGHA.4896[ at ]TK2MSFTNGP03.phx.gbl:
>
>> Are there any significant pro's/con's by managing/using indirect
>> sync over LAN as opposed to direct sync's?
>
> The only one is that you have to know the exact path/name of the
> target remote replica, whereas with indirect to a synchronizer,
> the synchronizer picks the remote partner replica from the managed
> replicas in the replica set.
>
> Direct replication is *much* simpler to implement (basically one
> line of code), and doesn't require starting and stopping the
> synchronizer on the local machine. Over a LAN, I'd never use
> anything else, except for some really good reason.
Of course, by "LAN" I mean "wired LAN". A wireless LAN is no better
than a WAN or dialup, because the connection is so unreliable in
comparison to a wired LAN. You wouldn't want to edit an Access
database across a wireless connection, so you don't want to do
indirect replication (which does the same thing as editing, i.e.,
opens the remote database across the connection).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Hi David,
I tried converting a managed LAN client to unmanaged/direct sync'ed by
replman on a server.
I failed. :-) I think the problem is that the embedded path of the replica
on the managed LAN client is "C:\Database\backend.mdb", and the replman
server needs it in UNC format - \\LANclient\Database\backend.mdb in order to
direct sync with it across the LAN.
I assume the fix is to create a new replica from replman on the server to a
network share on the LAN client PC?
Or is there a way to save/convert the path of the existing replica on the
LAN client PC so the server can see it?
Thanks,
Mark
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns9830D3419F5D5f99a49ed1d0c49c5bbb2[ at ]127.0.0.1...
[Quoted Text] > "Mark" <nospam[ at ]nospam.nospam> wrote in > news:OmMMGRVzGHA.4896[ at ]TK2MSFTNGP03.phx.gbl: > >> Are there any significant pro's/con's by managing/using indirect >> sync over LAN as opposed to direct sync's? > > The only one is that you have to know the exact path/name of the > target remote replica, whereas with indirect to a synchronizer, the > synchronizer picks the remote partner replica from the managed > replicas in the replica set. > > Direct replication is *much* simpler to implement (basically one > line of code), and doesn't require starting and stopping the > synchronizer on the local machine. Over a LAN, I'd never use > anything else, except for some really good reason. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"Mark" <nospam[ at ]nospam.nospam> wrote in
news:e7taa1XzGHA.4308[ at ]TK2MSFTNGP03.phx.gbl:
[Quoted Text] > I tried converting a managed LAN client to unmanaged/direct
> sync'ed by replman on a server.
>
> I failed. :-) I think the problem is that the embedded path of the
> replica on the managed LAN client is "C:\Database\backend.mdb",
> and the replman server needs it in UNC format -
> \\LANclient\Database\backend.mdb in order to direct sync with it
> across the LAN.
>
> I assume the fix is to create a new replica from replman on the
> server to a network share on the LAN client PC?
I'm not sure I understand what you mean, but, yes, any partner
replica that you're synching with directly needs to be in a share
that is accessible to the laptop users.
> Or is there a way to save/convert the path of the existing replica
> on the LAN client PC so the server can see it?
Seems to me you're doing it backwards. The laptop should be
initiating the direct synch, so it only needs to see the partner
replica on the server. It's much easier to share one hub replica on
the central server than it is to share the replica on every laptop.
In any event, synchs should be initiated by the laptop users,
anyway, so it would be the way you'd be doing it, in any case, no?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns983178B44A94Df99a49ed1d0c49c5bbb2[ at ]127.0.0.1...
[Quoted Text] > "Mark" <nospam[ at ]nospam.nospam> wrote in
> news:e7taa1XzGHA.4308[ at ]TK2MSFTNGP03.phx.gbl:
>
>
> Seems to me you're doing it backwards. The laptop should be
> initiating the direct synch, so it only needs to see the partner
> replica on the server. It's much easier to share one hub replica on
> the central server than it is to share the replica on every laptop.
> In any event, synchs should be initiated by the laptop users,
> anyway, so it would be the way you'd be doing it, in any case, no?
I have set up Replman on the server with three replicas in a 'farm'.
I have a few WAN users that run Replman on their notebook, and sync indirect
over VPN.
I have a few LAN users that run Replman on their notebook, ans sync indirect
over LAN. After reading this thread, I assumed you meant I can use replman
on the server to schedule direct syncs to these LAN clients.
So on the LAN notebooks, in replman I stopped managing their replica, synced
changes to the server, then this showed an unmanaged replica in the replman
'map' on the server. I then set up a sync schedule on the server replman
'map' to the unmanaged replica on the notebook.
I then realised that the path that's embedded in these LAN replicas is a
local "C:\.. " path, so the server replman couldn't find it to direct sync
to it. That's where I started asking about creating shares on the LAN
clients, so the server replman could be set to schedule & maintain all
sync's.
Is there anything wrong with this approach? I like the idea of complete sync
control on the server, rather than at the client. Our users had a habit of
taking the 'syncronizer' applet out of the statup menu.
Thanks,
Mark
|
|
"Mark" <nospam[ at ]nospam.nospam> wrote in
news:emGYjn9zGHA.3656[ at ]TK2MSFTNGP04.phx.gbl:
[Quoted Text] > "David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
> news:Xns983178B44A94Df99a49ed1d0c49c5bbb2[ at ]127.0.0.1...
>> "Mark" <nospam[ at ]nospam.nospam> wrote in
>> news:e7taa1XzGHA.4308[ at ]TK2MSFTNGP03.phx.gbl:
>>
>>
>> Seems to me you're doing it backwards. The laptop should be
>> initiating the direct synch, so it only needs to see the partner
>> replica on the server. It's much easier to share one hub replica
>> on the central server than it is to share the replica on every
>> laptop. In any event, synchs should be initiated by the laptop
>> users, anyway, so it would be the way you'd be doing it, in any
>> case, no?
>
> I have set up Replman on the server with three replicas in a
> 'farm'.
>
> I have a few WAN users that run Replman on their notebook, and
> sync indirect over VPN.
>
> I have a few LAN users that run Replman on their notebook, ans
> sync indirect over LAN. After reading this thread, I assumed you
> meant I can use replman on the server to schedule direct syncs to
> these LAN clients.
No. I meant that the laptop users (I'm assuming that any machines
that are permanently connected to the network are not using
replication at all, as there's no point in doing so, and doing so
would add unnecessary risk of conflicts) should use a direct synch,
initiated at the laptop. I do this with laptop users who synch
across a LAN:
1. provide a user interface for doing the synch on demand.
2. attempt a synch when they start the application (works only when
connected to the LAN).
3. attempt a synch when they exit the application (as in #2).
I would never schedule any synchs at all, because you have no
guarantee that they will be connected when the schedule says they
should synch. It makes much more sense to have the synch take place
when the user needs to synch, which is before and after an editing
session, and that can be determined by when the user starts and
exits the application.
> So on the LAN notebooks, in replman I stopped managing their
> replica, synced changes to the server, then this showed an
> unmanaged replica in the replman 'map' on the server. I then set
> up a sync schedule on the server replman 'map' to the unmanaged
> replica on the notebook.
This will "work," sort of, assuming the replicas on the laptops are
in a public share.
> I then realised that the path that's embedded in these LAN
> replicas is a local "C:\.. " path, so the server replman couldn't
> find it to direct sync to it. That's where I started asking about
> creating shares on the LAN clients, so the server replman could be
> set to schedule & maintain all sync's.
This is all backwards, from my point of view.
> Is there anything wrong with this approach? I like the idea of
> complete sync control on the server, rather than at the client.
> Our users had a habit of taking the 'syncronizer' applet out of
> the statup menu.
I would never bother to install ReplMan on laptops that aren't
synching over the WAN. I would also never want most users using
ReplMan -- I'd program even indirect synchs, using TSI Synchronizer
and/or JRO.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|