Adam,

Could you explain how there would be a duplicate using a system table ID and
record locking.

-myron kirby-
========================
>>Robert,
>>
>>There are problems with using Sys(2015). First, if you have a multiuser system and a bunch of folks are entering data into a table at the same time every day you may eventually get the same response from Sys(2015). Less likely is the possibility that the user will reset the system clock. The standard procedure, I believe, is to create a system table (call it System.dbf) that contains key fields and the next available system key (NextID) for that table. Then write a procedure which is called with parameters indicating the appropriate keyname, which corresponds to a system ID field in another table. Whenever you add a record to your table, first call your procedure which locks the appropriate System.dbf record, increments the counter (System.NextID), unlocks the System record, and returns the value of the next free key. You save the returned value as the ID value in the table you are adding a record to. Sometimes a key value will get skipped but you never get duplicates. You can
>>use system keys type N(10,0). If you need code to increment the counter, tell me your email address. Just make sure everything is locked before incrementing and unlocked afterwards.
>>
>>Adam
>
>These are good points, Adam, but the likelihood of a repeat code from SYS(2015) is actually less than a system table duplicate ID.