Yes I am using Access 2003 on windows XP. No I am not using GUID
as a primary key and thank you for your answer. I seem to be
having other issues that are causing the problem. When I created
the replica, I merely copied the replica instead of going through
the replication, thats when I get the error. Since then, I use
the replication to create multiple copies of the database, but
when I run the replication program, it replaces everything in the
master instead of telling me I have conflicts! I can't have the
replicas replacing everything because I have 10 people collecting
data that needs to be merged and not replaced.
Well, the Design Master shouldn't be used for editing.
There should be no problem initializing 10 laptops by copying a
replica of the DM to each of them.
You do need to consider the issue of replica priority. If you copied
your DM to the latops, you'd end up with a DM and 10 replicas, all
with the same replica priority (100). What you should probably do is
create one replica from the DM, which will have a priority that is
90% of its parent replica, thus, priority 90. Then copy that replica
to all the laptops. Then use the first replica (*not* the DM) for
your editing. The replica won't ever be edited, and won't ever be
used for anything except implementing design changes.
Further, you should have your app split, with a non-replicated front
end (forms, reports, queries, etc.) and a replicated back end
(tables only). Replication DOES NOT WORK for anything but tables and
queries, because Replication is a JET technology, not and ACCESS
one. Tables and queries are pure Jet objects (though they can have
properties specific to Access and not found by default in Jet
tables/queries), but forms and reports and so forth are purely
*Access* objects, not known to Jet at all, except as data in tables.
As to conflicts, all conflicts are resolved, but should be informed
of the results of every resolved conflict and allowed to reverse it
(using the conflict resolver). That is, when there's a conflict, one
of the records has already won the conflict, and all the conflict
resolver is telling you is "Hey! I already resolved this and this is
which record won. You may disagree and you can reverse it here."
If the conflicts are being resolved wrong, then it's likely that you
have a problem with replica priority somewhere along the line.
It is also the case that if you're having lots of conflicts, then
you may have a design error. You may be causing records to be edited
that don't need to be, and restructuring your data may eliminate
some of the data.
Replication works best in applications where there are only small
numbers of records that are edited in more than one replica at the
same time. It works best when at each replica new records are added
and edited, and those records tend to be used and edited only by the
users at that replica.
If your app has multiple replicas editing the same records all the
time, then either replication is not suitable, or you should
restructure the data in a way that will lessen or eliminate the
conflicts. I can't offer any particular general rules for how to do
that -- it would really depend on the particular application. But
the more normalized your data structure is, the less likely you are
to have conflicts.
You should also make sure you do *not* have natural keys with
cascading updates, because that could cause major, major problems. I
also generally remove cascade deletes from most relationships when
an app is replicated, as major problems can happen if you leave it
on (you can easily lose data that you don't want to lose).
