> > It's hard to describe it as a feature, but I'm afraid it
> > falls into the category of implementation artifact. What did
> > you expect to get back as the db_key of a record in each of
> > the trigger types?
>
> Exactly what you showed in your example! Amazing insight, you have! :-)
>
> Triggers fire on all events(Ins,Upd,Del), and record the changes into a
> central 'delta' table.
> The delta table is inspected on a regular basis, and Delta's are then
> migrated to the 'Replication Cortex', and redistributed cluster-wide.
> That table contains the source table, field, row, old value, new
> value, and
> a timestamp.
>
> If rdb$db_key isn't predictable, I'll have to have a rethink...
>
> Table design:
> CREATE TABLE mmk$delta (
> table CHAR(31) NOT NULL,
> field CHAR(31) NOT NULL,
> row char(8) character set octets NOT NULL,
> oldv BLOB sub_type text,
> newv BLOB sub_type text,
> stamp TIMESTAMP default 'now' NOT NULL,
> opcode INTEGER NOT NULL, /*1:ins,2:upd,3:del*/
> PRIMARY KEY(table,field,row,stamp,opcode)
> );
>
> Nige.

take a look at the logic behind the old replicator code at www.meta.com.au
it may help you
Alan