>
> 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.