> And there I was, thinking we had cured you of your bad old

desktop-database

> habits! :-<

// Hmmm. It appears that I need your book now, more than ever! Besides,
its not my fault, darn users insist on a robust product and it throws me off
sometimes :)

> Just DON'T do it. The point of having a generator is to ensure the
> integrity of your unique series. You don't then go and blow that by
> introducing key values that originated somewhere else.
>
> If you need to keep a memory of the old key, store an extra column for
> it. Then, if you have to import details that have a foreign key
> referencing that original key, you can pick it up on a Before Insert
> trigger on the detail rows and update the key.
>
> It's not just a question of knowing the "highest" value: what happens if
> an introduced gen value turns up that the receiving database's generator
> has already used...?

I have just recently added the ability to export/import from the database of
our application so I'm still getting my head around this. I can see the
occasion when a user may want to transfer data from one database to another
(such as a product menu) as well as another table where the FK and PK keys
that relate those two tables is already established. I was trying to figure
out how to handle situations like this mostly. Seems I will have to think
of another way.

Thanks again,

Lee