> Have you thought about situations where the same record
> (primary key) is
> changed on two different systems during the same transfer
> cycle? Perhaps
> this can't happen in your environment, but it is something
> that needs to
> be considered in a general case. My approach was to create an
> exception
> report and ask somebody to look at it.

I 'think' I have it covered.
Each table has a dtm_rstamp TIMESTAMP, that's NOT part of the PKEY. I'm
planning on using this for 'hinting' when PKEY collisions occur.
Server A, record X = bill, RSTAMP = last week
Server B, record X = henry, RSTAMP = yesterday

PKEY-Matching records are sent in order of rstamp, as it's a global time
reference. First in, first served. If a record changes the pkey info, and
subsequent updates fail, it'll log it to a failure table.
So record X on all servers will end up with 'henry', rstamp = yesterday.

>
> In my final version of the process I wrote, I created a feed-back loop
> that confirmed that a change/addition/deletion had indeed been applied
> at the destination system.I found that I needed this because nothing
> works perfectly in the real world. Until a verification record was
> received, I could "re-send" the change information as needed. In my
> case, I could not use commitment control because my servers were
> asynchronously connected - I actually sent the change data as email
> attachments. Maybe for you commitment control is feasible.

Two-phase commits, and intelligent triggers that 'exception' with good
messages if records aren't updated. Should work ok...

>
> I also had to deal with the making sure my replication
> process knew how
> to deal with metadata changes (i.e. new fields). Again, this may not
> apply in your situation.

Thankfully, no. (Well, not yet, anyway...)

Thankyou so much for your time and comments!

Nige.