|
|
Hi. I, with a few other trustees, run a small charity. We don't have our
own server, just a hosted (Linux based) web and FTP site and a bunch of home
PCs, which are, anyway, only ever online together by coincidence.
We have a (currently unreplicated) Access 2000 database that we share by
uploading and downloading to/from the FTP site, but of course this means that
only one of us can make entries into it at any time, the rest using it only
in "read only" mode.
We'd like to be able to replicate it and have several people entering data
and, of course, synchronize them all every now and again. Any hints on how
we can do this, using just our FTP site as a "store and forward" transport?
(I've tried putting the back end into MySQL on our hosted site, but it's a
sizeable and complex db and that turned out to be unusably slow. I've also
tried the TSI Synchronizer, but that seems to need shares as the dropbox).
Ideas welcome.
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote in
news:3CA4C995-06D5-40BF-ABCE-E647B487C3FE[ at ]microsoft.com:
[Quoted Text] > Hi. I, with a few other trustees, run a small charity. We don't
> have our own server, just a hosted (Linux based) web and FTP site
> and a bunch of home PCs, which are, anyway, only ever online
> together by coincidence.
>
> We have a (currently unreplicated) Access 2000 database that we
> share by uploading and downloading to/from the FTP site, but of
> course this means that only one of us can make entries into it at
> any time, the rest using it only in "read only" mode.
>
> We'd like to be able to replicate it and have several people
> entering data and, of course, synchronize them all every now and
> again. Any hints on how we can do this, using just our FTP site
> as a "store and forward" transport?
>
> (I've tried putting the back end into MySQL on our hosted site,
> but it's a sizeable and complex db and that turned out to be
> unusably slow. I've also tried the TSI Synchronizer, but that
> seems to need shares as the dropbox).
The TSI Synchronizer is nothing but a programmatic interface to the
Jet Synchronizer, just as Replication Manager is a user interface to
the same functionality. Jet Replication in its direct and indirect
forms depends on SMB networking as the basic substructure. That can
be provided on Linux by Samba, of course, but you also have to have
the Jet Synchronizer running, and that can't run on Linux.
Internet replication, on the other hand, uses FTP and HTTP, but is
hardwired on the server end to use IIS, which means you can't use a
Linux server.
I see no solution to your problem that would involve Jet
Replication.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Oh! Actually, I think there's a pretty simple solution...I was thinking too
hi-tech, then it occured to me, heck, you can do it by passing around a
floppy (well, memory stick), so any way of getting a replica from one PC to
another should work too.
I've played around and this seems to work. For the initial setup:
On PC-1: localdb-1 is replicated to centraldb. Centraldb is then moved
(i.e. uploaded then deleted from the PC) to the FTP site.
Then, on PC-2: centraldb is downloaded (then deleted from the FTP site),
replicated to localdb-2, and then uploaded back to the FTP site (and deleted
from the PC).
Further PCs that want replicas repeat the PC-2 step.
Now, everyone has a localdb-n replica and there is one centraldb replica on
the FTP site.
Everyone can now make changes to their localdb, and when someone wants to
share their changes -- and get any changes others have shared -- they move
centraldb to their PC, synchronize it with their localdb, and move it back to
the FTP site.
Of course, there has to be some care with file path and/or naming
conventions and, as everyone will (eventually) see all of the other copies in
the Synchronize dialog box, care must also be taken to only sync with yours
(so Access doesn't remove one it can't find).
There also has to be some kind of "lock" on currentdb, so two people don't
download it at the same time. Could be as informal as PC-1 synchronizes in
the mornings, 2 in the afternoons, etc, or a simple
rename-before-downloading, or a variety of more automated methods.
This seems a fairly simple solution to synchronizing replicas on PCs that
can't connect to each other (aside from passing around memory sticks), and
could also be adapted to synchronization by email attachments.
Or are there some gotchas that I haven't come across yet?
Marios
|
|
Ok....I see the gotcha.....what a shame :-(
I don't suppose there's any way to programmatically doctor MSysReplicas et
al to avoid the number of replicas growing?
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote in
news:BA57EE7C-E908-43A5-B128-96AB357A974F[ at ]microsoft.com:
[Quoted Text] > Oh! Actually, I think there's a pretty simple solution...I was
> thinking too hi-tech, then it occured to me, heck, you can do it
> by passing around a floppy (well, memory stick), so any way of
> getting a replica from one PC to another should work too.
As a one-time solution, yes -- you can use that to get a replica to
its destination location. But you can't send it back to synchronize
data, as this breaks the fundamental architecture of Jet
Replication.
> I've played around and this seems to work. For the initial setup:
>
> On PC-1: localdb-1 is replicated to centraldb. Centraldb is then
> moved (i.e. uploaded then deleted from the PC) to the FTP site.
>
> Then, on PC-2: centraldb is downloaded (then deleted from the FTP
> site), replicated to localdb-2, and then uploaded back to the FTP
> site (and deleted from the PC).
No, this will not work, as you're creating new ReplicaIDs each time
you do it, but killing the existing replica out of which it came.
This creates the dreaded "dead replicas" which can lead to
corruption and eventual loss of your replica set.
> Further PCs that want replicas repeat the PC-2 step.
>
> Now, everyone has a localdb-n replica and there is one centraldb
> replica on the FTP site.
That may get you the initial setup, but then you have to have a way
to synch in place.
> Everyone can now make changes to their localdb, and when someone
> wants to share their changes -- and get any changes others have
> shared -- they move centraldb to their PC, synchronize it with
> their localdb, and move it back to the FTP site.
No, you can't do that. Period. End of statement.
> Of course, there has to be some care with file path and/or naming
> conventions and, as everyone will (eventually) see all of the
> other copies in the Synchronize dialog box, care must also be
> taken to only sync with yours (so Access doesn't remove one it
> can't find).
>
> There also has to be some kind of "lock" on currentdb, so two
> people don't download it at the same time. Could be as informal
> as PC-1 synchronizes in the mornings, 2 in the afternoons, etc, or
> a simple rename-before-downloading, or a variety of more automated
> methods.
>
> This seems a fairly simple solution to synchronizing replicas on
> PCs that can't connect to each other (aside from passing around
> memory sticks), and could also be adapted to synchronization by
> email attachments.
>
> Or are there some gotchas that I haven't come across yet?
This will simply not work:
http://trigeminal.com/usenet/usenet009.asp?1033
And I've explained the whole thing at length here (all on one line):
http://groups.google.com/group/comp.databases.ms-access/msg/9f5a84194
fa6c653
In order to synchronize Jet replicas, there has to be the capability
for an occasional connection. Since your machines can FTP, the
capability is there. All you need is a VPN over the Internet and a
PC on the other end running the Jet synchronizer. That means a
Windows box, but it doesn't have to be a server, and it doesn't have
to store the hub replica on its own hard drive.
But you can't ship replicas back and forth and synch them, no matter
what method you use. This will break replication and you'll corrupt
your data.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote in
news:8A124461-E105-41E8-ACBF-2D8292CB199B[ at ]microsoft.com:
[Quoted Text] > I don't suppose there's any way to programmatically doctor
> MSysReplicas et al to avoid the number of replicas growing?
That's not the issue. The issue is that you're DOING IT WRONG. And,
no, only the db engine can write to MSysReplicas.
If they can FTP, they can use Indirect replication. You just have to
set up a VPN and then it will work. But you will need a Windows PC
on the hub end of the synch that is running the Jet synchronizer
(unless it can run in VMWare or something and a Linux box could run
it that way).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Yeah, yeah, I (now) understand. It does beg a question though: how does the
Briefcase do it?
Re VPN, remember, these are home PCs, and any of the machines can be down
for extended periods (weeks), when one (or more) of us goes away (the charity
builds schools & orphanages in developing countries).
Could we change which PC is the hub (without moving any replicas) and still
have it work?
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote in
news:07D983CC-707B-42E8-91F2-9AACE7ECE548[ at ]microsoft.com:
[Quoted Text] > Yeah, yeah, I (now) understand. It does beg a question though:
> how does the Briefcase do it?
Special code to handle it, I'd guess, as it's designed for a
specific situation, with one user and two computers.
> Re VPN, remember, these are home PCs, and any of the machines can
> be down for extended periods (weeks), when one (or more) of us
> goes away (the charity builds schools & orphanages in developing
> countries).
Er, so what? You have a Linux server (presumably running Samba), put
your drop box on that server and run the synchronizer on a Windows
workstation on the same network as the Linux server. Or try the
VMWare option.
> Could we change which PC is the hub (without moving any replicas)
> and still have it work?
That's what I suggested. The location of the data file and the
dropbox is independent of the machine that is running the
synchronizer.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"David W. Fenton" wrote:
[Quoted Text] > Er, so what? You have a Linux server (presumably running Samba), put
> your drop box on that server and run the synchronizer on a Windows
> workstation on the same network as the Linux server. Or try the
> VMWare option.
No, as I said in the original post, we do not have our own server, we use a
HOSTED, Linux based, ftp and web site. I.e. we rent space on a commercial
provider, on a system over which we have no control, beyond what we upload to
our directory tree.
The only possibility (short of increasing our internet budget n000%) for a
VPN is between our home PCs.
So, can we move around which PC the synchronizer runs on?
Marios
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote in
news:D8344C9D-D8DC-4B0D-903F-4618604588D8[ at ]microsoft.com:
[Quoted Text] > "David W. Fenton" wrote:
>
>> Er, so what? You have a Linux server (presumably running Samba),
>> put your drop box on that server and run the synchronizer on a
>> Windows workstation on the same network as the Linux server. Or
>> try the VMWare option.
>
> No, as I said in the original post, we do not have our own server,
> we use a HOSTED, Linux based, ftp and web site. I.e. we rent
> space on a commercial provider, on a system over which we have no
> control, beyond what we upload to our directory tree.
>
> The only possibility (short of increasing our internet budget
> n000%) for a VPN is between our home PCs.
>
> So, can we move around which PC the synchronizer runs on?
Hmm. The synchronizer has to have the machine on which the replicas
it manages be visible at the time it synchs. But there can be only
one synchronizer per replica at a time. That is, a replica can be
managed by only one synchronizer at a time.
Keep in mind, though, that only one end of the synch needs to have a
managed replica. Both ends need the synchronizer, but only the end
that is remote from the location where the synch is initiated needs
to be managed.
That's another way of describing a star topology, where there's a
central hub, with a managed replica, and the machines at the points
of the star do not have their replicas managed. But that means the
synchs always have to be initiated by the PCs at the points of the
star.
You could have more than one center to your star, though, and any
remote PC could synch with any synchronizer that was visible to it.
But that's an awful lot of trouble for a situation that would be
solved by having one PC on all the time with a full-time Internet
connection.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|
[Quoted Text] > But that's an awful lot of trouble for a situation that would be
> solved by having one PC on all the time with a full-time Internet
> connection.
I don't know of many peole that would be happy to leave their PC up and
running in an empty house when they went away for several weeks. I certainly
wouldn't be comfortable with it....
Anyway, thanks for explanation; maybe I'm being a bit thick, but I don't
quite understand (possibly my understanding of "managed" is faulty).
Could I ask you to please give a simple example of how we'd do this with,
say, just 3 PCs (if that's the right minimum number to give a working example
for), all of which have a replica that they want to indirect sync with the
others from time to time, and any one of which might disappear for an
extended period (but with the remaining two still wanting to sync with each
other).
Thanks
Marios
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote in
news:9A7A26A1-837E-40F7-806D-7FCA1EE4AB16[ at ]microsoft.com:
[Quoted Text] >> But that's an awful lot of trouble for a situation that would be
>> solved by having one PC on all the time with a full-time Internet
>> connection.
>
> I don't know of many peole that would be happy to leave their PC
> up and running in an empty house when they went away for several
> weeks. I certainly wouldn't be comfortable with it....
Is there no institutional center for this project?
> Anyway, thanks for explanation; maybe I'm being a bit thick, but I
> don't quite understand (possibly my understanding of "managed" is
> faulty).
That has to do with how the synchronizer works. A managed replica is
one that a synchronizer is responcible for, and will synch when an
indirect synch is requested.
> Could I ask you to please give a simple example of how we'd do
> this with, say, just 3 PCs (if that's the right minimum number to
> give a working example for), all of which have a replica that they
> want to indirect sync with the others from time to time, and any
> one of which might disappear for an extended period (but with the
> remaining two still wanting to sync with each other).
In that case, all three would have to be managed by the synchronizer
so they could be the remote synch point. This causes certain
problems, because you can't compact a managed database while the
synchronizer is running (you will often keep the synchronizer
running all the time so that an incoming synch can complete without
a pre-arranged synching time).
It really is easier to find a central location where a single PC can
act as the hub for the synch, always on and always connected to the
Internet. That's far, far easier than provisioning for synchs with
any randomly chosen partner replica.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|
[Quoted Text] > Is there no institutional center for this project?
No, we run a distributed virtual office (this is the 21st century you know
:-). As we do most everything electronically there'd just be no sense --
indeed, it would be financially irresponsible -- to spend donors' funds on a
"real" office, just for the sake of having one.
The cost of renting even a small office for a year would be around the same
as building a village primary school in Asia or Africa, so given the choice
between having an office we don't actually need and building one less school
a year, well, that's easy....
Besides, the 5 trustees that run the charity, which gets around $250k of
donations and involves around 120 volunteers a year, are spread over 100
miles, so having a "central" office isn't practical anyway.
The only slight nuisance in "moving" the virtual office is changing where
the post goes, as that involves a trip to the post office. Phones and, of
course, everything internet based just plain work in a distributed
environment.
Anyway, thanks for the advice. I'll play with it and see how painful it
really is. I guess at worst we could acquire a spare laptop to use as a hub,
and then physically move that when needed (and teach the others about IP
addresses... :-)
Marios
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote in
news:5EB10E5C-2C9F-4F91-AA3F-8627D67302D1[ at ]microsoft.com:
[Quoted Text] > Anyway, thanks for the advice. I'll play with it and see how
> painful it really is. I guess at worst we could acquire a spare
> laptop to use as a hub, and then physically move that when needed
> (and teach the others about IP addresses... :-)
You should look into a dynamic DNS host. That way, they won't need
to know anything about the IP address, and the machine will be
accessible via a hostname any time it's connected to the Internet.
Of course, you'll want it properly firewalled from the Internet.
And you can use the Windows VPN setup, workstation to workstation. I
do this from my home machine to that of one of my clients (though
they have a de facto fixed IP address -- i.e., it hasn't changed in
two years, even though it's technically dynamic).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|