>David,
>
>>If you want a unique, primary key, and don't need an incremented, numeric key, you can use SYS(2015) for the default value. It is faster than using a table to maintain an incremental key, and won't generate duplicates if the NextID table ever gets messed up.
>
>Yeah, I know. Very, very nasty. And the clients can't do anything to resolve the problem if he can't change it on its inputform.
>
>>There is a very tiny possibility that multiple users can generate a duplicate key if they both call the function at the exact same millesecond.
>
>Not if you use a RLOCK() before increasing the value.
>
>Walter,

Walter,

I wasn't very clear. I meant there is a tiny possibility of SYS(2015) returning the same value if two users on different machines called the routine during the same millisecond.

I just tested it with a program that uses a FOR NEXT loop to insert 20,000 records into a small table using SYS(2015) to generate a key. Two concurrent FoxPro sessions running this program simultaneously on a 866 Mhz PIII machine generated 33 duplicates. So I would say that this method is not good in a multiuser environment where keys are being generated very rapidly (Hundreds or more per second).

Or trap the duplicate key error and try it again. That may be the best solution. I little slower, but more reliable.