So, what IS your question???

Peter


>Thank you for putting forth a concerted effort. However, you skipped the line that updates the counter. Only one of us can do that, the other person will have to go back and get another key.
>
>Counter is at 12345
>
>You get the hightst current key at 13:00:00:00, it's 12345.
>I get the highest key at 13:00:00:01, it's 12345!
>
>You inciment the counter at 13:00:00:02, its now 12346
>I try to incriment the counter, but there is no record "where kKeyCtr = tcFld and nCtr = 12345"
>I loop and get a new counter, 12346
>I inciment the counter, its now 12347
>
>You write your record with a PK of 12345 at 13:00:00:02
>I write my record with a PK of 12346 at 13:00:00:03
>
>Nobody gets a duplicate key error.
>counter is at 12347
>
>>Are you looking for advise or are you testing us?
>>lets do that in slow moion:
>>
>>You get the hightst current key at 13:00:00:00, it's 12345.
>>I get the highest key at 13:00:00:01, it's 12345!
>>
>>you write your record with a PK of 12345 at 13:00:00:02
>>I write my record with a PK of 12345 at 13:00:00:03
>>
>>I will get a duplicate key error.
>>
>>If you see it any other way, I relly would like to know.
>>
>>
>>Peter
>>
>>
>>>Can either of you please support your claims? I am not locking, because I don't need to lock. Locking takes time, locks get left in place, locks cause things to wait, and locks are not as portable to an SQL server. (I don't necessarily want to use an identity field.) Also, algorithms that use locks need to flip the alias around, and you then run the risk of it not getting flipped back to the right one.
>>>
>>>So, do you guys still think it can fail? If so, please show steps.
>>>