> "Michael" <michael.howden[ at ]gmail.com> wrote in
> news:1158401415.962374.192480[ at ]i42g2000cwa.googlegroups.com:
>
> > I have a database which needs to run in 2 different offices
> > (Jakarta and Banda Aceh - it's for an NGO working with the Tsunami
> > relief). There is a shared network drive ( the "I: drive" - hosted
> > in Jakarta) between the 2 offices (set up using MS Server).
> > However the connection is too slow to run the DB over.
>
> If it's an always-on connection, then your best solution is to *not*
> use repliation at all, but to host the application on a Windows
> Terminal Server on one end of the connection. This will be much,
> much easier to set up and maintain than indirect replication (which
> will be required for a WAN synch).
>
> > I am facing a problem which I think is best solved by replication.
> > I have scanned the forum posts, read the documentation and FAQs,
> > and this is what I have come with:
> >
> > Place the Back End of the database on the "I: drive". Create a
> > replica for the users in Jakarta (keep the Design Master safe
> > somewhere else on the "I: drive"). When I am in Banda Aceh, I will
> > use the Design Master (running from the "I: drive" in Jakarta) to
> > create another Replica, which I will put on a network drive in the
> > Banda Aceh office. Is this feasible so far?
>
> Don't create a replica across the WAN link. Instead, just copy an
> existing replica. It will end up as a new replica as soon as it is
> opened. This is the only scenario in which a file system copy is OK,
> i.e., in initializing your replica in its new location.
>
> > The users in the 2 different locations can use their different
> > versions, which can then be synchronized weekly.
> >
> > Which brings me to my next question: Direct or Indirect
> > Synchronization? Because the "I: drive" is accessible from Banda
> > Aceh, could I do direct synchronization?
>
> No, for the same reason that you can't just use a linked table -- if
> the connection is too slow/unreliable to use Access across it, then
> it's too slow/unreliable for direct replication. You *must* use
> indirect replication in this type of scenario, or you'll risk
> corruption/data loss.
>
> > This seems easier, because I
> > can just train someone to use the inbuilt tool in Access (I don't
> > have the Replication Manager). Or is this unadvisable, because the
> > connection is slow, and maybe not the most reliable - which will
> > result in corrupting the files? I think that this is more likely.
>
> That's correct.
>
> > I believe this leaves me the only other options of using Michael
> > Kaplan's TSI Synchronizer Object to do indirect synchronization.
> > I've downloaded the files (synch40.dll and synch40.h), although
> > I'm not too sure what to do with them. Presumably link the dll
> > (VB: Tools>References), but what do I do with the H file?
> > Can I use the TSI functions with a replica created from Access?
>
> I don't understand the question. The TSI functions are intended to
> be used with MDB files (whether created with Access or not).
>
> > One question, unrelated my currently problem: why couldn't
> > indirect syncrohnisation work between 2 computers connected with a
> > flash drive which is carried between them? With the dropbox on the
> > flash drive? There's probably a really good reason, but it beats
> > me!
>
> Because both dropboxes have to be visible to both synchronizers.
> Synchronizer A puts messages in Dropbox B, and Synchronizer B reads
> the messages from Dropbox B, and then puts messages in Dropbox A,
> which Synchronizer A reads. What you've described would only work in
> the case where a synch is one-way and requires only one stage. That
> is not how most indirect synchs work -- they have multiple stages of
> message files dropped into each dropbox and read from there.
>
> It would likely take several trips back and forth with the flash
> drive to get the two databases completely synched.
>
> > Will I need to re-link the tables after each synchronization?
>
> No. Why would you think you would?
>
> > There is one problem. I am only here for a few weeks. I may need
> > to make changes to the database after I have left. I don't presume
> > that this will be a problem if I am changing the Front End.
> > However after replication, will I will no longer be able to get
> > the users to email me the Back End File, so I can make changes to
> > it, and then email it back?
>
> Absolutely not. If they email you a replica and you open it, it's no
> longer the same replica (Jet assigns it a new Replica ID). For a DM,
> that means it's no longer the design master.
>
> Once a replica has been used, it has to be used and synched IN
> PLACE. That means:
>
> 1. No email
>
> 2. No copying
>
> 3. No moving (except with the MOVE REPLICA command provided by Jet)
>
> > I presume the solution in this situation is to write code in the
> > front end, which will automatically make any changes which I need
> > (but is only run when the front end is connected to the back end).
> > Is there a way I could get the staff here to send me a Non-Replica
> > copy of the database to me?
>
> Again, the best way to do this is with Windows Terminal Server. You
> will then be able to remotely alter the DM via a Remote Desktop
> session.
>
> > I would appreciate any feedback, if you think that this is
> > feasible, any tips, or ideas where I may experience challenges.
>
> Your circumstances don't work at all for replication. The Windows
> Terminal Server situation is *always* best for two locations that
> want to share data and have a WAN/Internet connection available at
> all times.
>
> --
> David W. Fenton
http://www.dfenton.com/> usenet at dfenton dot com
http://www.dfenton.com/DFA/