>Another developer (currently on vacation) created a field (Claim) as an autoincrementing integer, to act as a primary key (the index itself is just a Regular, not Candidate). But now we are getting bad data, and the field values seemed to work okay for the first 25000 or so - and then reset to 1. So now there are are hundreds of bad records. So the last 800-odd records have duplicated claim numbers. The immediate question is, whether there is any way programmatically to determine what the next autoinc value is, and then how to reset it. The other question is how it got screwed up, and what to do to prevent it.

Just don't use autoinc - then you don't care <g>. Quite a few colleagues of mine have been bitten by now by some way or another by autoinc. But for future less troubled times:

a) candidate keys will at least stop errors from building up inside your tables
b) a simple but very helpful thing in troubled times is the existance of DIFFERENT TS fields tCreate, tChange, tDelete.
c) if the data IS important/expensive: log all entries/changes. Save every day the log for the last 3 days. Gives you a way "to play" back and a bit of fault redundancy through the 3 days overlap.

Usually b) and c) can be implemented with minimal HW cost - hope your app falls into the range where this approach is possible.

HTH

thomas