Re: Making a copy of the current database using code

"Rick Wannall" <wannall@xxxxxxxxxxxxx> wrote in
news:mNhfg.36425$4L1.21950@xxxxxxxxxxxxxxxxxxxxxxxxxx:

Study up on Replication/Synchronization. . . .

No, this really has nothing to do with the question being asked.

. . . If you want to make multiple
copies, and allow users to enter data into the different copies,
and integrate all that back into a master somewhere, this is the
way to do it.

Assuming you have a split architecture where you're replicating only
the data, that's one solution to the problem you describe, but it
only works if the individual users can connect to a common network,
or a chain of networks (A->B->C->B->A, where C does not have to be
able to connect directly to A, but there has to be a path from C to
A through an intervening network connection).

If you synchronize all of them over time you wind up with all the
data in all the copies. If you get data from one copy back into
the master and you're finished with the copy for good, you can
just delete it.

This is just so much complete bull***. Access/Jet *does* care if
you delete the source replica, as it has a record of it.

. . . Access
master doesn't care about whether any of the copies still exist or
not.

Yes, Jet *does* care. Any replica that participates in a synch is
then known to every other replica and the list of replicas is
maintained in perpetuity until you delete the replica from the
replica set (something that can only be done by attempting a synch
with the deleted replica, which means the network path has to be
accessible). Deleting replicas can lead to data errors, data
corruption and eventual loss of the entire replica set. At the very
least, once it develops, you can't say for certain whether or not
the synched replicas are actually identical or not, so the data
might as well be corrupted, since it's no longer reliable.

It's very easy to set up.

And you are clearly a moron who knows absolutely nothing about
actually using Jet replication over the long term.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Quantcast