>>Vladimir,
>>
>>Thanks for your response, but I was not talking about SQL Server. I was talking about VFP native tables (not even part of database -free tables) and the ability to autoincrement field without using autoinc field added in VFP8. As far as I know the only other reliable method is to use a separate table to hold the latest ID (one record per table with ID). The approach is described in Craig Bernston's website and I used it myself successfully.
>>
>>Now I'm facing a situation when we're not using external table for IDs, but just taking the last ID from the table itself. I'm afraid there is no way to avoid possible duplicates, though with an immediate check we can minimize the risk. I don't know what to tell. That we should re-design the current approach?
>
>Why not have a fake record with a key value of -1 (or some other preset value) and some other field which would hold the last key used? Then you'd have to lock that record, increment the value, read the value into a variable, unlock the record, add a new record with that value as the key. This way you do have a separate location which holds the key counter, only it's in the same table. Downside: you need one numeric field which wouldn't be included in any totals anywhere, i.e. a strange record you always have to filter out.

This may be a good idea (e.g sort of using NextID table inside the same table). But I'm not certain if that table has other ID field except this one...

Anyway, I didn't really had a chance to look into this issue either due to other multiple requests...