Re: 4 Synch Questions

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi David

Well...thanks to you I got (nearly) the whole thing working today in a test
environment on the local network between two pcs. Replicas and synchronizers
on the 'server' pc and 'remote' pc. Scheduling also working. Expaniding on a
question from a couple of days ago, I found out that you can specify a
particular mdw when launching ReplMan - just right-click the shortcut in
Start > Programs > Microsoft Office XP Developer > Replication Manager 4.0
and in the target path put something like:
"C:\Program Files\Common Files\Microsoft Shared\Replication Manager
4.0\replman.exe" /wrkgrp "c:\syncTest\syncSystem.mdw"

Thanks for all the information you've helped me with. Just to verify:
1 Server: Folder 1 contains the Backend_Hub.mdb & Backend_Production.mdb.
Folder 2 is the (shared) Server dropbox.
2 Laptops: Folder 1 contains the Backend_Hub.mdb. Folder 2 is the (shared)
Laptop dropbox.

I'm now writing a step-by-step guide to all of this which I hope will be
much easier to walk through than the current documentation. Again, if it
weren't for you my application would not be working.

Regards

Nigel


"David W. Fenton" wrote:

> "=?Utf-8?B?TmlnZWwgU2NvdHQ=?=" <nigel(removethisbit)@amscott.com(and
> this.net)> wrote in
> news:9D7904EE-4E54-4237-8111-4863A50FA137@xxxxxxxxxxxxx:
>
> > I agree about the awful documentation of Jet Replication. I
> > imagine many people give up trying because it is so poorly
> > explained. Perhaps now the Microsoft Access team have their
> > version of JET and do not have to comply with the SQL Server
> > people they could really make replication something special. . . .
>
> My understanding is that replication is dead in Access 12, replaced
> by SharePoint functionality to (attempt?) to replicate the same
> functionality.
>
> > . . . The
> > potential for Access uptake, just for this, could be massive
> > because it is so useful and definitely has a niche. Sharepoint
> > seems pretty limited if Microsoft are not going to let developers
> > get into the data structure of it.
>
> It's also dependent on a server infrastructure that Jet replication
> does not depend on. That's the same problem with Outlook as Exchange
> client -- all the good stuff in it is tied to MS Exchange, and most
> small businesses can not afford (and do not want) to have to
> administer an Exchange server, which anyone who has done so knows is
> a huge pain in the ass.
>
> > Replicas (& DropBoxes):
> >
> > 1. Server or Elsewhere: Design Master hidden from the users but
> > able to synch intermittently to keep it from expiring and to
> > propogate design changes.
>
> Yes. The key is that the DM should never be in production use.
>
> > 2. Server: Backend_Hub (managed by the
> > Server Synchronizer), Backend_Production (edited by LAN users,
> > unmanaged but regular schedules to synch with Backend_Hub).
> > Optional replica farm - probably more requirement here than on the
> > Laptops. (Server Dropbox)
>
> Sounds right.
>
> > 3. Laptop1: Backend_Hub,
> > Backend_Production. Optional replica farm. (Laptop1 dropbox)
>
> I see no real reason for anything but a single replica on the
> laptop. Having a replication hub is only necessary when the
> production replica is in a shared folder. That should *not* be the
> case for the laptop production replica, so I don't see any need for
> setting up extra replicas on the laptop. I would advise some kind of
> backup replica on the laptop, but would normally implement that via
> a direct synch with a backup replica that happens automatically each
> time the application front end is closed.
>
> > 4. Laptop2: Backend_Hub, Backend_Production. Optional replica
> > farm. (Laptop2 dropbox)
>
> The laptops should be identical in their replication setup.
>
> > 5. LAN pcs: Linked directly to Backend_Production (no replicas and
> > no dropboxes)
> >
> > In the above, Laptop.Backend_Hubs are replicas of the
> > Server.Backend_Hub, created by opening Server.Backend_Hub on each
> > respective Laptop and creating new replicas from it using ReplMan
> > on each Laptop.
> >
> > When you say "I know many people recommend putting the dropboxes
> > on the server" do you mean both the Server and Laptop dropboxes,
> > as opposed to just the Server dropbox?
>
> Yes, THe idea is that having the laptop dropboxes on the server
> means that you don't have to worry about any security settings
> except those on the server (this is of particular benefit when there
> is no domain controller involved for the laptops to authenticate
> against; of course, *with* a domain controller, the laptops when
> they are disconnected are not authenticating against the domain
> controller, anyway, so I have never seen the benefit here). There's
> also the idea that you're keeping certain administrative problems in
> one place. But I just don't think it's a good idea to set up a
> syhnhronizer to depend on resources that aren't always going to be
> present.
>
> > Synchonizers:
> >
> > 1. Server or Elsewhere: Design Master synch intermittently with
> > Backend_Hub
>
> I wouldn't schedule this, because it's possible to pass corruption
> during a synch.
>
> > 2. Server: Backend_Hub scheduled synch with
> > Backend_Production hourly at most, preferably longer depending on
> > number of updates, etc. Backend_Hub scheduled synch with replica
> > farm can be every 30 minutes or possibly less (since these aren't
> > being edited anyway).
>
> Well, that all depends on your determination of how much data
> latency you can tolerate. I'm for fewer scheduled synchs, but I also
> believe that replication is most appropriate for apps where you're
> not trying to use replication to replace zero latency solutions.
>
> > 3. Laptop1: Manual synch with the server.
> > 4. Laptop2: Manual synch with the server.
>
> Again, laptops should be identical, so there's no need to describe
> each one separately.
>
> > 5. LAN pcs: Linked directly to Backend_Production (no replicas and
> > no dropboxes)
> >
> > How near am I?
>
> With the emendations above, it looks pretty much correct to me.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc
>
.

Relevant Pages

  • Re: Replman - Managing multiple sets of application databases
    ... The laptop should be ... replica on the server. ... It's much easier to share one hub replica ... would add unnecessary risk of conflicts) should use a direct synch, ...
    (microsoft.public.access.replication)
  • Re: Basic setup advise
    ... Each installation of RM **requires** its own dropbox. ... make an additional replica for your server -- one that is not the DM. ... replication manager running on a PC and a laptop. ...
    (microsoft.public.access.replication)
  • Re: 4 Synch Questions
    ... It's also dependent on a server infrastructure that Jet replication ... > unmanaged but regular schedules to synch with Backend_Hub). ... > Optional replica farm - probably more requirement here than on the ... case for the laptop production replica, so I don't see any need for ...
    (microsoft.public.access.replication)
  • Re: Replication to laptops - how do you do this?
    ... We have a main office which has the server. ... out in the field gathering information into the replica. ... So I don't know which is the best synchronization method to use. ... each laptop needs to have a replica of the data file. ...
    (microsoft.public.access.replication)
  • Re: Replication to laptops - how do you do this?
    ... We have a main office which has the server. ... out in the field gathering information into the replica. ... need those 4 to connect and synch up to the version onthe branch office PC ... each laptop needs to have a replica of the data file. ...
    (microsoft.public.access.replication)