I almost hate to ask this question and I'm sure I know what the answer
is, but I'm really scratching my head over the problems I'm seeing.

The issue involves replication in an environment where four remote
people use their own local copy of a database and synchronize
periodically throughout the day with a server database.  The
application assigns unique internal autoinc ID ranges in each of the
published tables so that anyone can create a record, synchronize, and
get everyone elses additions, changes, and deletions.

This is working well for all new records created.

A couple of months ago, I converted their old data (which was in FoxPro
for DOS) to the new system, but there were some bugs in how I organized
the synchronization.  To make a long story short, some of the records
that were created right after the data conversion, were assigned
internal IDs in the range of a test user I had created.  I corrected
the situation and just left the new records with their IDs, figuring it
didn't matter what internal ID was used as long as there were no
duplicates.  There were also cases where an update process reported an
attempt to modify a record that didn't exist; so I manually created the
record and re-ran the update to let it go through completely.

To make sure there were no duplicates, I created a stored procedure
that runs at application startup that restarts the autoinc field of
each published table to the last value available in that table for that
user's range.  That also seems to work.

There is one key person that touches everyone's records by performing
final billing and shipping functions, prints out a copy for faxing, and
eventually marks the record as "closed".  As changes are made to the
records, we all have been making sure that the changes are replicated
to the other users.  Again for all newly created records, everything is
working fine.

The problem is that when she makes changes to the records that were
created with the wrong IDs, the changes don't get replicated.  I don't
think it has anything to do with the actual ID numbers, because she
frequently modifies records newly created by other people (which, of
course, have different internal autoinc IDs) and we all get the changes.

What I am wondering about is if there's some internal flag at the
record level that is set or cleared when a record is replicated.  I
just think it's weird that most records synchronize just fine, but
these certain records that had problems a couple of months back, but
need changes now, are not getting synchronized when others in the same
table are getting synchronized.

We've been working around the issue for now by having each person
delete their copy of the record, synchronizing, then having one person
re-create the troublesome record.

Any words of wisdom here would be appreciated!


--
David Cornelius
CorneliusConcepts.com

David,

<< What I am wondering about is if there's some internal flag at the record
level that is set or cleared when a record is replicated. >>

No, on the internal flag.  The only two things that happen are this:

1) A table is published, and all inserts, updates, and deletes to that table
are logged along with the publisher ID of the table that performed the
modification(s).  If the modification(s) are occurring due to a LOAD UPDATEs
statement, then the publisher ID of the table performing the modification is
added to the internal manifest (list of publisher IDs) for the modification
and logged as such.  This is done so that EDB can know when a modification
has already been loaded by a particular published table, thus preventing it
from being loaded again.

2) When a SAVE UPDATES is executed against a particular published table(s),
then all logged updates for the table(s) are saved to the updates file and
then removed completely.

<< I just think it's weird that most records synchronize just fine, but
these certain records that had problems a couple of months back, but need
changes now, are not getting synchronized when others in the same table are
getting synchronized. >>

More than likely you've got something messed up with the primary keys for
the involved tables.  The number one reason why an update would not load
would be a mismatched primary key.  The primary keys must match, or else the
replication will not work properly.

--
Tim Young
Elevate Software
www.elevatesoft.com

> More than likely you've got something messed up with the primary keys
> for the involved tables.  The number one reason why an update would
> not load would be a mismatched primary key.  The primary keys must
> match, or else the replication will not work properly.

Thanks for the info.  I'll double check how the primary keys, autoinc
IDs in each person's range, are restarted.  I wonder if it's just the
first one they create each day...


--
David Cornelius
CorneliusConcepts.com