Replication
Andi Plotsky
give the Replica feature in Access2000 a whirl. I'm not sure I'm THAT
impressed.....but maybe I'm just doing something wrong. I'll outline the
issues below and then maybe someone who has experience with replicating this
way can tell me if this is the route I should take, or if I should just use
my own routine which compares strings for each field.
1) I've developed this in Access2000. The databases have 3 tables which
need to be synchronized (a total of 287 fields in all 3 tables). Most of
the field values are integers (1-9), but there are some text strings as
well. The client computers are running Access2003. Would this be a major
problem? Should I change the original database to an Access2003 version?
Of course, I will create the replicas on the REAL machines.
2) I have two conflicting manuals - Osborne says the priority level for the
Master is 100; the MS White paper says it's 90. I want both to have the
same priority because there really isn't an authoritative source - any could
be correct - we'll need to make a decision on conflicts on a case by case
basis. It looks like the 90 is correct - I set the replica priority to 90
and MOST conflicts popped up. Does anyone know how to check the priority
level of a database AFTER it has been turned into a replicable database?
3) Creating the replicas and running the synchronization runs pretty fast,
but the Conflict Resolution process is DREADFULLY slow on my 450 MHz machine
w/ 256K of memory, running Windows2000. It knows that there are x number of
conflicts in each table - but takes forever to bring each one up and to
Resolve it, once I've made my decision. Is this typical? My client has new
machines with WindowsXP - will it still be a problem?
4) It found MOST conflicts, but missed one. It seems like it just ignored
this field (in one test it found others in the same record, in another test
where this was the only field that was different, it did nothing) - it
didn't give either database a priority - didn't overwrite either set of
data. Is this a priority issue or something else?
5) I heard that Replication can screw up Security stuff, but these databases
don't have any security features - the computers, which are dedicated to
them have passwords. If I decide to Encrypt the database replicas to send
them in for updating the Master, will I regret it? (Actually I haven't
tested this to see if it's even possible to replicate and encrypted
database).
Any advice/warnings will be greatly appreciated!
Andi
--
Andi Plotsky
IRIS, LLC
2859 Galahad Drive
Atlanta, GA 30345
404-321-9459 (office)
404-636-2331 (fax)
iris...@bellsouth.net
David W. Fenton
news:0CZEd.13247$zy6....@bignews5.bellsouth.net:
> I need to synchronize 3 databases (1 Master and 2 replicas). I
> thought I'd give the Replica feature in Access2000 a whirl. I'm
> not sure I'm THAT impressed.....but maybe I'm just doing something
> wrong. I'll outline the issues below and then maybe someone who
> has experience with replicating this way can tell me if this is
> the route I should take, or if I should just use my own routine
> which compares strings for each field.
>
> 1) I've developed this in Access2000. The databases have 3 tables
> which need to be synchronized (a total of 287 fields in all 3
> tables). Most of the field values are integers (1-9), but there
> are some text strings as well. The client computers are running
> Access2003. Would this be a major problem? Should I change the
> original database to an Access2003 version? Of course, I will
> create the replicas on the REAL machines.
I don't know about the interactions of replication and the A2K2 and
A2K3 features that allow the use of A2K-format databases as native
formats. I do know that A2K could not edit data in an A97 replicated
back end. I would hope that the problem there was difference of Jet
version.
However, if you're replicating front-end objects (e.g., forms,
reports, etc.), which you shouldn't be doing under any circumstances
(replication is for Jet data, not for Access objects, and will
eventually irretrievably corrupt your database if you're attempting
to replicate Access objects), it could be that the Access version
*will* make a difference. The only way to find out is to test.
If the A2K3 clients can edit the A2K data, then you're set.
> 2) I have two conflicting manuals - Osborne says the priority
> level for the Master is 100; the MS White paper says it's 90. I
> want both to have the same priority because there really isn't an
> authoritative source - any could be correct - we'll need to make a
> decision on conflicts on a case by case basis. It looks like the
> 90 is correct - I set the replica priority to 90 and MOST
> conflicts popped up. Does anyone know how to check the priority
> level of a database AFTER it has been turned into a replicable
> database?
The conflict priority of the Design Master is completely irrelevant,
as it should *never* under *any* circumstances be used for editing
data. Your design master is like your source code -- it should be
locked away and taken care of, as it's your master copy. Yes, it
periodically needs to be synched with the replicas (because if you
don't, it will eventually expire), but since there are no data
changes in it, its higher priority doesn't matter.
Principle: all data editing takes place only in REPLICAS, never in
the Design Master.
> 3) Creating the replicas and running the synchronization runs
> pretty fast, but the Conflict Resolution process is DREADFULLY
> slow on my 450 MHz machine w/ 256K of memory, running Windows2000.
> It knows that there are x number of conflicts in each table - but
> takes forever to bring each one up and to Resolve it, once I've
> made my decision. Is this typical? My client has new machines
> with WindowsXP - will it still be a problem?
If you're having more than a couple of conflicts a week, then you
probably have either a design error in your data structure, or an
application that is not suitable to replication.
Replication really only works well when very few records are edited
in more than one location.
> 4) It found MOST conflicts, but missed one. It seems like it just
> ignored this field (in one test it found others in the same
> record, in another test where this was the only field that was
> different, it did nothing) - it didn't give either database a
> priority - didn't overwrite either set of data. Is this a
> priority issue or something else?
It may have resolved the conflict incorrectly, particularly if your
Design Master is involved, since the wrong data may have won.
Remember, you only see conflicts to resolve when the synchronization
process hits a tie between the replicas.
> 5) I heard that Replication can screw up Security stuff, . . .
I've never heard of this.
> . . . but these
> databases don't have any security features - the computers, which
> are dedicated to them have passwords. If I decide to Encrypt the
> database replicas to send them in for updating the Master, will I
> regret it? . . .
You're *sending* replicas for synchronization? THIS IS AN INCREDIBLY
BAD ERROR. Replicas *must* be synchronized IN PLACE, where they live
on a regular basis, or you'll be creating dozens of "dead replicas"
that will eventually lead to lost data. This is probably the source
of all your conflicts, as in Jet 4, replication errors get treated
as conflicts to be resolved.
> . . . (Actually I haven't tested this to see if it's even
> possible to replicate and encrypted database).
It is, but you have to encrypt the master. I don't know if this
propagates to the replicas or not.
> Any advice/warnings will be greatly appreciated!
I think you have a lot of homework to do about the basics of
replication. You are clearly making a massive number of elementary
mistakes that if not rectified will eventually lead to data loss, if
not the loss of the entire replica set.
Resources for learning:
microsoft.public.access.replication
Investigate those and then come back if you have additional
questions. Indeed, you're likely to get better advice in
microsoft.public.access.replication than here in this newsgroup,
where I'm one of a handful of regular posters with any extensive
experience with Jet replication.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Andi Plotsky
Maybe I should have explained the scenario better. What I'm considering to
be the 2 replicas are actually residing on laptops where the users will be
gathering information from a variety of medical records in various cities.
Periodically (daily?), they will want to send their databases back "home" -
to update the Master. Then the next morning, the new replicas (updated with
the data from any user who has sent in data the previous day) will be
available for download from the server (or FTP site).
And, yes, these are only data tables. The "local" databases (on the
laptops) will link to the tables in the replicas. Isn't this a valid
scenario? It was my understanding that only the Design Master had to stay
on the original computer forever.....
"David W. Fenton" <dXXXf...@bway.net.invalid> wrote in message
news:Xns95DBC43A6D4DAdf...@24.168.128.78...
David W. Fenton
> Thanks for your speedy reply -
>
> Maybe I should have explained the scenario better. What I'm
> considering to be the 2 replicas are actually residing on laptops
> where the users will be gathering information from a variety of
> medical records in various cities. Periodically (daily?), they
> will want to send their databases back "home" - to update the
> Master. Then the next morning, the new replicas (updated with the
> data from any user who has sent in data the previous day) will be
> available for download from the server (or FTP site).
Nope. It's not a valid replication scenario. It's wrong, it's not
supported, it will lead to loss of data.
Read up on the website and newsgroup I cited, but here's the reason
why it's such a horrendous mistake to do it the way you're
describing:
When a replica is created, it is given a unique GUID that is its
ReplicaID. That ReplicaID is associated with global location of that
replica, which would be its UNC path, or the machine name plus the
drive path. Say you have a Design Master, ReplicaID 1 on your home
server. You connect your two laptops to the network and via the
Access UI use direct replication to create a replica on each laptop.
The replica on Laptop1 in the folder C:\Databases is ReplicaID 2,
and the replica on Laptop2 in the folder C:\Databases is ReplicaID
3.
If you rename or move a replica, the next time it is opened, Jet
checks if it still has the same name and is in the same location as
it was in the last time it was opened. If it's *not*, then it
generates a new ReplicaID and changes that replica's ReplicaID. From
your point of view as a human being, it's exactly the same data
file, but from the point of view of Jet replication, it's now a
completely fresh, previously unknown replica.
So, when you email ReplicaID 2 from Laptop1 back to home base, as
soon as its opened, it becomes ReplicaID 3. When you email it or FTP
it back to Laptop1, it becomes ReplicaID 4. Each time you do this,
you change the ReplicaIDs, thus creating new replicas.
Why is this a problem?
Well, it isn't necessarily unless there are any data errors in a
synchronization. Jet 4 eliminated data errors as separate from
conflicts, but they are a different kind of conflict. An example
would be if there were a collision on a primary key in two different
replicas -- you can't add the two new records from the two records,
since there can be only one record with a particular PK value.
Now, say you generated this duplicate PK in ReplicaID 2 vs. a new
record inserted in ReplicaID 3. When you email those two replicas to
the home base and open them, you now have ReplicaID 4 (original #2)
and ReplicaID 5 (original #3). When you synch with the home base, it
records a data error (conflict) with records that came from
ReplicaID 4 and ReplicaID 5. Now, assume you are unable to resolve
the error, but decide it doesn't matter, and so you email the
replicas back to the laptops in the field. As soon as they are
opened, they are now ReplicaID 6 (original #2) and ReplicaID 7 (3).
You still have an unresolved data conflict.
Now, you make more changes and email back to home base, which synchs
with what are now ReplicaID 8 (2) and ReplicaID 9 (3). Say that at
this point you notice the conflict. But the conflict was generated
between ReplicaID 2 and ReplicaID 3, but you *can't* resolve this
BECAUSE THOSE REPLICAS NO LONGER EXIST.
The result is that:
1. the two replicas have a permanent data conflict that can only be
removed by someone who has the expertise to do so (and it can be
very time-consuming with large numbers of dead replicas).
2. the two replicas HAVE DIFFERENT DATA IN THEM, a difference that
can never be resolved by synchronization.
In other words, using the method of sending files back and forth,
you are creating a situation that is very likely to quickly produce
a situation where YOUR REPLICAS ARE NO LONGER IDENTICAL.
You said you had lots of conflicts every day. This is no doubt
because of all these dead replicas (there should never be large
numbers of conflicts to resolve if they are only data). And these
errors multiply arithmetically. Each time you change the ReplicaIDs,
you multiple the number of data errors (since the replicas with the
new ReplicaIDs still have these records in them that have never been
successfully synched). With two such replicas, each time you synch,
you double the number of basic errors.
And you don't know what state your data is actually in -- you have
no idea if it's the same in all three replicas or not.
Are you beginning to see why it's a really bad idea to do what
you're doing?
The only valid architecture for Jet replication is one in which the
PCs where the replicas live can be periodically connected via
network and synchronized across that network. There are three ways
for this to happen:
1. direct replication: connect the laptop to the home base LAN, and
synchronize with the central replica.
2. indirect replication: connect via network (LAN, WAN, dialup) and
synchronize via the Jet synchronizer (which sends and receives the
changes, rather than opening both data files across the network
connection as in indirect replication).
3. Internet replication: using FTP for replicas that live on PCs
that have IIS installed, do indirect replication via FTP across the
Internet (instead of across an SMB LAN).
ALL OTHER SCENARIOS WILL LEAD TO DATA CORRUPTION/LOSS.
> And, yes, these are only data tables. The "local" databases (on
> the laptops) will link to the tables in the replicas. Isn't this
> a valid scenario? It was my understanding that only the Design
> Master had to stay on the original computer forever.....
The split design is fine. The Design Master should, indeed stay on
the original computer, but it should not be the copy that is used as
the central point for synchronization with the replicas and as the
editable copy at the home site.
The Design Master should be kept in a safe place and synched once a
month, at most.
Andi Plotsky
program that I wrote once that can be adapted to do what I'm looking for - I
think it will be easier and less prone to problems due to US not being
careful about synchronization.
Thank you for your time in explaining the possible problems I could
encounter.
Andi
"David W. Fenton" <dXXXf...@bway.net.invalid> wrote in message
news:Xns95DCC3C4B64CBdf...@24.168.128.78...