>>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