The sys(3) call is not made successionally. The user would have to enter more than one request within 1000th of a second. This would be impossible. Not only that, the id's generated look something like this:

51426652
51426652
51426652
51426652
51431147
51426652
51426652
51426652

It is strange that is will throw in a new id and then go back to the previous id.

>The help file says sys(3) can have problems on fast computers...why don't you just pause for a couple of milliseconds and see if that helps?
>
>>>>I am using the sys(3) function to assist in generating unique id's. I have over 300 clients using this functionality without a problem. However, I recently had a client who was receiving duplicate id's. There problem was fixed by replacing the computer. I now have another client with the identical problem and they are not willing to accept that their computer is to blame.
>>>>
>>>>Has anyone ever seen this kind of problem before. The problem is not related to CPU speed since the id is only generated per request and it would be impossible to input requests that quickly.
>>>>
>>>>Any help would be greatly appreciated.
>>>
>>>Usually, unique ID (for table.primarykey purposes) is generated by having separate counters table (like Tastrade sample). I don't know, is it applicable to your case or not.
>>
>>All other tables in this application are done that way but this is a unique situation. It is working great for all the other 299+ clients. I'm thinking it is a glitch in the BIOS.