Synchronizing between 2 offices some thoughts please

[Les Girvan]

Hi Guys,

I am looking for ideas on keeping a database synchronized between 2 offices,
London & Manchester. I know the easiest way would be to create a web based
database which we would both log into and process from that point, but I
assume we would loose the efficiency of the local reporting and other
aspects of a local copy of our data.

The other thought would be for us to pass data between the offices on a
frequency and maybe run an update query to sync the data.

The database is a contacts database so it is mainly updating call notes made
during the course of the day.

Any thoughts, opinions or considerations would be most welcome. My
experience in access in moderate, but willing to learn

Many thanks
Lez

 

[Douglas J. Steele]

Take a look into Replication. Good places to start are
http://office.microsoft.com/en-us/access/CH063664271033.aspx and
http://support.microsoft.com/kb/282977

As well, Michael Kaplan, one of the authors of the Replication FAQ in the
second reference above, has useful stuff at http://www.trigeminal.com/

Note, too, that there's a newsgroup specific to replication if you have any
questions/problems: microsoft.public.access.replication

 

[Scott McDaniel]

Hi Guys,

I am looking for ideas on keeping a database synchronized between 2 offices,
London & Manchester. I know the easiest way would be to create a web based
database which we would both log into and process from that point, but I
assume we would loose the efficiency of the local reporting and other
aspects of a local copy of our data.

Replicaiton is one option. Replication involves designating one database as a Design Master, and then making replicas of
that database to distribute to others. In your case, you'd build a replica and deploy that to your remote office.
Replication allows you to synchronize the replicas back to the DM whenver needed. Note that replicated data can be
somewhat "stale" - that is, it's only as updated as the last synchronization.

Replication FAQ:
http://support.microsoft.com/kb/282977

Kaplan's site:
http://www.trigeminal.com/resources.asp?1033

MS Site:
http://office.microsoft.com/en-us/access/CH062526841033.aspx

You could also use a Terminal Server setup in one of the offices. TS allows you to keep all data on one box, which means
the data is as fresh as can be. It also can ease maintenance chores, since there's only one backend database to deal
with. Of course, TS can increase your cost of ownership - depending on the version of TS you use, you would need TS
licensing, a VPN to connect the offices (you can use TS over the internet, but most business offices would need the
tighter security of a VPN), and someone to maintain this.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

 

[Les Girvan]

Cheers Guys,

Thanks for that information, will look into this option further

Regards
Les

 

[David W. Fenton]

I am looking for ideas on keeping a database synchronized between
2 offices, London & Manchester. I know the easiest way would be to
create a web based database which we would both log into and
process from that point, but I assume we would loose the
efficiency of the local reporting and other aspects of a local
copy of our data.

That wouldn't by any stretch of the imagination be a simple thing to
implement!

The other thought would be for us to pass data between the offices
on a frequency and maybe run an update query to sync the data.

The database is a contacts database so it is mainly updating call
notes made during the course of the day.

Any thoughts, opinions or considerations would be most welcome. My
experience in access in moderate, but willing to learn

I have been doing replicated Access apps since 1997. These days,
when I want to have two fixed-location offices share data like this,
I set up Windows Terminal Server in one of the offices. Your
existing Access app will run completely unchanged in this
environment. The cost of licenses is very low (USD40 for a single
CAL, no price breaks for volume purchases). The end-user experience
is often as good or better than running it across a 100Mbps LAN.

Replication in this environment would require the complexities of
indirect or Internet replication, as a direct synch across the
Internet is not going to be safe or reliable. This is a lot of work,
and really only something that someone experienced should be
implementing.

 

[David W. Fenton]

Replicaiton is one option. Replication involves designating one
database as a Design Master, and then making replicas of that
database to distribute to others. In your case, you'd build a
replica and deploy that to your remote office. Replication allows
you to synchronize the replicas back to the DM whenver needed.

The DM should not be involved in regular production editing or daily
synchronizing. It is a special replica, the only one in which you
can make design changes, and it should be kept in a safe location
and synched only often enough to keep it from expiring (the default
retention period is 1000 days; I generally set up a monthly synch
with the DM). Only replicas should be used for editing and regular
synching.

Note that replicated data can be
somewhat "stale" - that is, it's only as updated as the last
synchronization.

But any two replicas are only one synch away from being identical.

The issue you're referring to is "latency," and in an app where no
latency can be tolerated, replication is not satisfactory.

I would say that the Terminal Server option is by far the best. The
only place where I would say Jet Replication is a must-have is with
laptop users who need to edit the data in the field and then synch
with the main office. If they can wait to synch when they get back
to the office, and across the LAN, it's *very* easy to implement
safely. If they need so synch with the "mother ship" while in the
field, it's a lot more complicated than that.