John,

>I've heard a bit about having another table with the next ID. I didn't implement a next ID table because I figured the chance of the ID table getting out of sync with the base table was as great as the possible problem with the duplicate IDs. Do you have a neat trick to make sure the next ID table always stays in sync with the underlying base table?

Under normal circumstances it won't generate duplicate key's, however it can skip keyvalues if you make use of buffering and revert changes.

I'd say that having a ID table is a very good id(ea). You can use your reorganize routine or program to synchronize the ID's.

As for determining the maximum keyvalue in the table:
USE Table ORDER TAG pk DESCENDING
should point you to the record with the maximum pk value

Walter,