>>Actually, lock (in counter table) is requried if you want to get 100% unique value for primary key immediately.
>
>Nothing is going to return a value "immediately", something has to execute, right? I think it will return a unique value quicker than when using locks.
>
>> However, if you prefer to beat table down until you will really get correct key, i.e. get first one, try to update, trap the error if not unique, get next value, update again etc.
>
>The alternative is to keep checking for the record to become unlocked.
>
>> It will also work, why not, but what the purpose? Locking is not really bad, and SQL-Server also uses it, behind the scene most of times.
>
>Most of the time, the process will be 1. get value, 2. update. This will always be quicker than 1 try to lock, 2. test for success, 3 get value, 4 update, 5 unlock. (I would hope that VFP can lock/update/unlock quicker than I can). The only time I can see it being equal or slower is during a collision, which is the exception, not the norm.
>
>> Do not take me wrong. If it works for you, that's good, but in reality there is nothing to prove here.
>
>What I am asking for is "can anyone show me anything wrong with this?" So far, you and Craig have given me your hunches (and worded them as facts), but no support. At least you seam to have acknowledged that you think it will work, correct?
>

Carl,
Actually I did not check your code carefully, because, firstly, I trust Craig :-), and also AFAIK lock is always required. Would I try to investigate what form of a wheel, round or square, is preferable? Probably not. So, I am not in position to give any kind of aknowledgements here. Let's look at this realistically. Yes if there is no conflict then without a lock it will be faster. But how much faster? Would you claim that it will comprise anything but negligible?
PS: take it easy. The purpose of UT is really to give support, but no longer as it's really required.