Replication manager

[John]

Hi

I have setup replication between a laptop and the server. The db syncs fine
manually. Now I would like the process to be somehow automatic. Either when
the laptop connects to the server or scheduled somehow. Can I do something
like this with replication manager? What are the easy steps to accomplish
this?

Thanks

Regards

 

[David W. Fenton]

I have setup replication between a laptop and the server. The db
syncs fine manually. Now I would like the process to be somehow
automatic. Either when the laptop connects to the server or
scheduled somehow. Can I do something like this with replication
manager? What are the easy steps to accomplish this?

Replication Manager allows you to schedule synch between managed
replicas on two different computers.

What that means is:

1. the synchronizer has to be running on both PCs.

2. the schedule has to be set up.

3. the two PCs must be able to see each other on the same network
(LAN, dialup or WAN).

The key problem with this is getting the synchronizer running on the
server. For some reason, Microsoft never thought it was worth
engineering the synchronizer to run as a service, so it has to be
launched in an interactive logon on the server, and left running by
locking the console. If your server has Windows Terminal Server
running on it, or you have an administrative logon to the server,
your user could initiate to a remote desktop session on the server
and start up the synchronizer.

But I wouldn't seriously suggest this.

The synchronizer doesn't actually have to be running on the server,
just on a machine on the same LAN. But you'd just be moving the same
problem from the server to a workstation, which would need to be
running and logged on, so that's not much help.

 

[Guest]

With replication manager being removed from Access 2003, is there a way to
accomplish the same exact process without Replication Manager? If so, how?
Through a macro or VB Code?

Thanks!

 

[John]

What if the laptop is in the field and not connected to the network, would
the synchroniser schedule cause any problem?

Regards

 

[John Vinson]

What if the laptop is in the field and not connected to the network, would
the synchroniser schedule cause any problem?

Nope. Just wouldn't run since there's nothing there.

John W. Vinson[MVP]

 

[David W. Fenton]

With replication manager being removed from Access 2003, is there
a way to accomplish the same exact process without Replication
Manager? If so, how? Through a macro or VB Code?

Replication Manager was never a part of Access. It was a part of the
Office Developer Tools, so you have to get that to use it.

I do not know if Microsft is no longer packaging ReplMan with their
current developer tools. Perhaps they are doing that to force people
to use JRO instead, which would be a stupid decision on their part.

I don't know.

I don't do replication in Access 2003.

Indeed, I hardly do any replication any more at all, since Windows
Terminal Server became a viable platform for hosting distributed
apps.

 

[John]

I am not clear why we need to run synchroniser on the server? Would it not
be enough to do it on laptop alone? Why not?

Thanks

Regards

 

[Cheval]

You do and you don't. Read on.

Part 1 of reasoning: There are only three forms of MS Access replication;
Direct, Indirect(synchronizer) and Internet(synchronizer). Direct is done
via code or via you clicking "Synchronizer Now" on the toolbar. It's best
when you have a good quality network where Access can open both replica
files and read/write data to them. Indirect is for poor quality networks
where Access replicates via writing message and data files to the other
computers mail box. Which is why you need a synchronizer at both ends, so it
can keep checking for new replica message files. Internet is same as
indirect but the message files are ftp'ed.

Part 2: The point of a synchronizer is two parts, schedule replication at
set times (Only down to the 15 minute mark) and have reliable replication
over a poor quality network (like dialup phone). If you need to have a
synchronizer on the laptop, then you have a poor quality network and
therefore need a synchronizer on the server.

If your procedure is that the user goes off site, does their thing, then
comes back on site and connects to the server, then it would be better to
code Direct replication. In our application, every time the application
loads it checks for the server, if found, replicates to it. Also if the user
has made a whole lot of changes, then they can initiate replication from a
menu option on the switchboard.

So in summary of your questions:
"I am not clear why we need to run synchroniser on the server?" Not really a
question, but if you need to run a synchronizer at all, then it needs to be
at both ends.
"Would it not be enough to do it on laptop alone?" Yes, if your laptop
synchronizer replicated Directly to the server's replica, but this is
*pointless* as you should just code the Direct replication. And No for
Indirect replication as explained above.
"Why not?" Because you would be creating unnecessary problems for yourself.
I am not clear why we need to run synchroniser on the server? Would it not
be enough to do it on laptop alone? Why not?

Thanks

Regards

 

[John]

Thanks, that was very clear. Just one question, how does one check for the
presence of the server?

Thanks

Regards

You do and you don't. Read on.

Part 1 of reasoning: There are only three forms of MS Access replication;
Direct, Indirect(synchronizer) and Internet(synchronizer). Direct is done
via code or via you clicking "Synchronizer Now" on the toolbar. It's best
when you have a good quality network where Access can open both replica
files and read/write data to them. Indirect is for poor quality networks
where Access replicates via writing message and data files to the other
computers mail box. Which is why you need a synchronizer at both ends, so
it
can keep checking for new replica message files. Internet is same as
indirect but the message files are ftp'ed.

Part 2: The point of a synchronizer is two parts, schedule replication at
set times (Only down to the 15 minute mark) and have reliable replication
over a poor quality network (like dialup phone). If you need to have a
synchronizer on the laptop, then you have a poor quality network and
therefore need a synchronizer on the server.

If your procedure is that the user goes off site, does their thing, then
comes back on site and connects to the server, then it would be better to
code Direct replication. In our application, every time the application
loads it checks for the server, if found, replicates to it. Also if the
user
has made a whole lot of changes, then they can initiate replication from a
menu option on the switchboard.

So in summary of your questions:
"I am not clear why we need to run synchroniser on the server?" Not really
a
question, but if you need to run a synchronizer at all, then it needs to
be
at both ends.
"Would it not be enough to do it on laptop alone?" Yes, if your laptop
synchronizer replicated Directly to the server's replica, but this is
*pointless* as you should just code the Direct replication. And No for
Indirect replication as explained above.
"Why not?" Because you would be creating unnecessary problems for
yourself.
I am not clear why we need to run synchroniser on the server? Would it not
be enough to do it on laptop alone? Why not?

Thanks

Regards

 

[Cheval]

Well in most cases you have a drive mapped to it, say Z drive. So some code
as simple as:

If (Len(Dir("Z:\ServerRep.mdb"))>0) then RunRep

will work.
Thanks, that was very clear. Just one question, how does one check for the
presence of the server?

Thanks

Regards

You do and you don't. Read on.

Part 1 of reasoning: There are only three forms of MS Access replication;
Direct, Indirect(synchronizer) and Internet(synchronizer). Direct is done
via code or via you clicking "Synchronizer Now" on the toolbar. It's best
when you have a good quality network where Access can open both replica
files and read/write data to them. Indirect is for poor quality networks
where Access replicates via writing message and data files to the other
computers mail box. Which is why you need a synchronizer at both ends, so
it
can keep checking for new replica message files. Internet is same as
indirect but the message files are ftp'ed.

Part 2: The point of a synchronizer is two parts, schedule replication at
set times (Only down to the 15 minute mark) and have reliable replication
over a poor quality network (like dialup phone). If you need to have a
synchronizer on the laptop, then you have a poor quality network and
therefore need a synchronizer on the server.

If your procedure is that the user goes off site, does their thing, then
comes back on site and connects to the server, then it would be better to
code Direct replication. In our application, every time the application
loads it checks for the server, if found, replicates to it. Also if the
user
has made a whole lot of changes, then they can initiate replication from a
menu option on the switchboard.

So in summary of your questions:
"I am not clear why we need to run synchroniser on the server?" Not really
a
question, but if you need to run a synchronizer at all, then it needs to
be
at both ends.
"Would it not be enough to do it on laptop alone?" Yes, if your laptop
synchronizer replicated Directly to the server's replica, but this is
*pointless* as you should just code the Direct replication. And No for
Indirect replication as explained above.
"Why not?" Because you would be creating unnecessary problems for
yourself.
I am not clear why we need to run synchroniser on the server? Would it not
be enough to do it on laptop alone? Why not?

Thanks

Regards

 

[David W. Fenton]

Well in most cases you have a drive mapped to it, say Z drive. So
some code as simple as:

If (Len(Dir("Z:\ServerRep.mdb"))>0) then RunRep

I think drive mappings are a very old-fashioned method for accessing
network resources, especially for laptops that aren't always
connected to the LAN.

Since a mapped drive always resolves to a UNC path, you can just as
easily do the same thing with a valid UNC path:

If (Len(Dir("\\Server\Share\ServerRep.mdb"))>0) then RunRep

 

[John]

Hi

Thanks for that. I have searched in the help but can't find a way to run the
replication via code. How would one go about doing that?

Thanks

Regards

 

[Cheval]

Using UNC pathing creates a lot of headaches in MS Office, MS Access
included. Especially on Novell servers. It's not recommended as milage
varies.

Well in most cases you have a drive mapped to it, say Z drive. So
some code as simple as:

If (Len(Dir("Z:\ServerRep.mdb"))>0) then RunRep

I think drive mappings are a very old-fashioned method for accessing
network resources, especially for laptops that aren't always
connected to the LAN.

Since a mapped drive always resolves to a UNC path, you can just as
easily do the same thing with a valid UNC path:

If (Len(Dir("\\Server\Share\ServerRep.mdb"))>0) then RunRep

 

[Cheval]

http://www.trigeminal.com/

Read the code samples. The tools are fantastic as well, except for the
initial learning curve that is.
Hi

Thanks for that. I have searched in the help but can't find a way to run the
replication via code. How would one go about doing that?

Thanks

Regards

 

[David W. Fenton]

Using UNC pathing creates a lot of headaches in MS Office, MS
Access included. Especially on Novell servers. It's not
recommended as milage varies.

Er, anyone using Novell with Jet databases is asking for trouble in
the first place. I wouldn't allow any of my clients to store
production MDBs on a Novell server -- too much chance of corruption.

I know of no headaches whatsoever with UNC paths in MS Office. Care
to give examples? I've been setting up clients to use UNC paths
instead of mapped drives for nearly 10 years now (since about 1997,
I guess), and nobody seems to be having any problems.

Only a carefully managed network with drives mapped from user logon
scripts can be relied on to have consistent drive letters. And, even
then, a user could change them if she wanted to.

Secondly, in my experience, over time, sysadmins tweak their drive
mappings, so they are never reliable. UNC paths can never be changed
without renaming a server or the shares involved.

If there were a performance advantage, to mapped drives, perhaps
they'd be worth it, but since there isn't, especially in code, I see
no reason to use anything but UNC paths. It insulates my
applications from changes in things that are beyond my control.

 

[George Nicholson]

Access 2000 Developer's Handbook, Volume 2. (Litwin, Getz & Gilbert/Sybex).
Chapter 9 has about 100 pages on the subject.

--
George Nicholson

Remove 'Junk' from return address.

Hi

Thanks for that. I have searched in the help but can't find a way to run
the replication via code. How would one go about doing that?

Thanks

Regards