> Unfortunately we need an id for a row that won't change over time,
> so I can't use RDB$DB_KEY. As for the existing primary key, it is no
> good either since the date stamp is not guaranteed to be unique
> either... ex - the date is reset on the server, etc (and I can't
> change the existing database schema). It seems that I'm stuck with
> keeping a list of sent rows to compare against. Any other ideas?

Can you please explain what does the "I can't change the existing
database schema" means?

If it is about some other legacy applications, then maybe there's a
solution. I am thinking about creating an updatable view with the name
of the table you have (that one has to be dropped). Then your updates
and inserts would go to the base table, but other legacy applications
would select from the view.

Roman