> > OK.
> >
> > > The delta table is inspected on a regular basis, and
> > Delta's are then
> > >
> >
> > A problem with using the db_key - aside from the fact that it
> > doesn't seem to do what you need - is that all versions of a
> > record share a single db_key value.
>
> At first, this shocked me, but it makes sense.
> The version of the record doesn't matter too much, as I have the delta's
> that have changed it.
> But, as db_key is misbehaving, a rethink is in order.
>
>
> > What I think I might look at, in your situation, is using
> > generator values to tag record versions. Timestamps are too
> > coarse a measure - currently whole seconds, soon to be
> > clunks (100 microsecond chunks, IIRC). In Firebird you're
> > unlikely to hit a duplicate clunk, but when Vulcan introduces
> > real parallelism, timestamps won't be unique, however fine
> > the measurement. Generators, on the other hand, are pretty
> > reliable, and (she says, madly counting on her fingers)
> > you're about as likely to run out of a 64 bit generator as
> > time in the universe, at least time as measured by early 21st
> > century computers.
>
> Yep. Plenty of unique identifiers there. Luckily, only a few pages of code
> has been done so far, so any changes will be swift.
> But if db_key isn't reliably caught by the trigger, I'll have to build a
> system to match the normal primary key on each table, meaning lots more
> fields, and slower searching.
>
> Alan's got something to look at over at meta.com.au, but I don't know
> pascal, so it's a hard slog figuring out if he uses triggers or not...
>
> Thanks for your fantastic help, Ann!
>
> Nige.

you don't have to know pascal. you need to look at the way the replicator
installs it's triggers and the tables it installs to manage the process. It
uses PKs. It does not have to store the OLD and NEW values as you seem to be
doing. It merely records the tablename and PK value of the record which has
been inserted/updated/deleted. The replicator does the rest.
Alan