>John,
>I get what you're saying but I'm still more confortable with sys(2015).
>Try this:
>?padr(alltrim(sys(1)) + alltrim(str(seconds()*1000)), 20, "0") + padr(alltrim(sys(1)) + alltrim(str(seconds()*1000)), 20, "0")
>?sys(2015)+sys(2015)
>
>There seems to be less chance of a dup with sys(2015).
>
>Thanks for the input
>%)
>Barry Horton
>
>>>>- take padr(alltrim(sys(1)) + alltrim(str(seconds()*1000)), 20, "0"), this creates a key that is virtually impossible to corrupt, but, the possibility exists, so, in my Table operations class, when I issue a save, I check to see if tableupdate() is sucessful, if not, I check to see if it is a primary key problem, if so, I simply replace the last "0" in the key with a "1".
>>>>
>>>>I know it sounds a little hokey, but it works like a champ, an added benefit, is that it becomes very reliable when you allow users to work remotely, and upload their changes!
>>>
>>>Sounds good but no locking mecanism.
>>
>>You don't really need to lock the table, except for the VFP auto lock when issuing the tableupdate(). Since the table op's class handles the unliklihood that the unique key fails, I don't need to issue a lock when the record is added...Or should I say that at this point, it has neven caused a problem by not issuing a lock!
>>
>>Happy New Year, BTW!
>>
>>John

BTW, there is a KB article, Q106708, that is MS suggestion of how to use sys(3) & sys(2015) to creatue unique keys. This also contains some probability of duplication factor numbers.