>>>I've taken over an app that uses sys(2015) to generate values for a candidate key. Users are getting "Unique index violation" errors occacionally and have to re-enter data. I cannot change the data structure to hold more characters.
>>>
>>>I'm replacing 2nd and 3rd chars with info from userid, in hopes of greater chance of uniqueness.
>>>
>>>Any better ideas for a temporary quick fix?
>>>
>>>Much Thanks
>>>Jeff
>>
>>Jeff,
>>If you could go for a new generator it'd be better. Till then for the structure you've on hand :
>>first char. of sys(2015) is always an underscore. Then rest of chars represent the time in base 36. It's safe to change first char. You could do this for example :
>>-Keep a table with MAC addresses of users
>>-On entry to app find station's MAC address in table
>>-Store chr(recno('Stations')) && oApp.cStation = GetStation()
>>-Stuff(sys(2015),1,1,oApp.cStation)
>>Field default value might look like :
>>Stuff(sys(2015),1,1,iif(type('oApp.cStation')='C',oApp.cStation,GetStation())
>>
>>This would allow up to 255 stations to produce unique IDs (provided none of the computer clocks falls back - very unlikely to produce an existing key though)
>>PS: Still doing some kind of generating a new id. However from performance point this would be fast IMHO.
>>sys(2015) generated value could be casted to base62, base222-255 to provide more space for stationID and station count limit increases to 0xFFFFFFFF.
>>Wearing my flamesuit another side note (bad I don't have enough knowledge to defend or demonstrate this, just personal experience) :
>>Even though I use integer surrogate keys a lot I don't put integer field as the first field. If I can't find any other char field I place a dummy char field as the first field. Using integer field as first one caused me enough headaches in the past (as per corruption).
>>Cetin
>
>Cetin,
>Are you saying that when you physically create a table that you do not place surrogate int key first? I've always put the key at the top( int or not), as a matter of convience.
>
>Thanks
>Jeff

Yes. My tables with an integer key look like :

field1 c(n) && might be a dummy field or one that really is part of table
keyfield i
otherfields...

PS:As noted in reply to Elmer I've no proof or demonstration that it's any better.
Cetin