> >(auditable series is taken via a
> >differnet route).
> >
> >
> What do you mean by this?

Often people want their PKs to have meaning wihtin their database. They also
want to allow users the ability to edit these PK values. Then on top of
that, they want these values to not have gaps in their sequence.
This is a whole other discussion about which I am rather outspoken.

> Suppose table A has a trigger (after insert or after update), which
> inserts records automatically into table B. This happens all the time,
> while people are using the database, quite independantly from the
> replicator. Obviously, each record that gets inserted into table A
> generates an line in the log table, and the same goes for table B. Then,
> the replicator kicks in, and replicated table A first. In the remote
> database, the same thing is going to happen : when I insert a record
> into table A, a certain number of records are automatically going to get
> inserted into table B. This has nothing to do with replication, that's
> just the way I designed my database (admittedly not very well!). So then
> afterwards, table B will get replicated, and all the same rows are going
> to get inserted again. So it will either generate a PK violation, or, it
> the PK values aren't the same, it will simply duplicate all the lines.
> So I can't think of any other (nor simpler) solution to this problem
> than to do as I did, that is, to not record the type of change that
> occured, but merely indicate which record was affected. That way, in the
> case I described above, we can simply notice that the records are
> already present, and so we update rather and inserting. This is very
> flexible.
>

The automatic trigger that inserts a record into table B on insert/update to
table A will not fire under replication since the USER is recognised here
too. All replication takes place by way of single inserts/updates and
deletes, as if all tables are standalone. That's the model I have used for
years, but as I say - each to his own.

Alan