>>c(36) works best in my experience (but maybe because I work with SQL server a lot). Perfromance would be affected is a myth IMHO. Search for COMB keys on the internet for details explicitly related to SQL server.
>
>
>Cetin, in VFP performance is affected by the length of the key. I made testing last year, an decided to go with integers just because of this. In MS-SQL it might be another story, I don't know.
>
>And for the ones who say "storage is cheap these days" just would like to add: this is the one of the paths to make bloated software, just like "performance is not such an issue as in the past due to new processors".
>If you keep relaxing you will produce more a more bloated software.

True, but then I'd rather spend my time rethinking the design - are the tables truly normalized, are we pulling the same data over and over by various SQL statements, what bottlenecks are there, is there too much unnecessary code in the refreshes, do we still carry workarounds for bugs which were fixed in VFP6 etc etc.

I'm guilty as anybody else of spending a lot of time tweaking a feature or two until they performed smoothly - and in some cases, rewriting the whole thing fourth time until it became blazingly fast. For one of the latter, I was lucky, because it was something we really needed, and it became a feature that set us apart from competition.

For some other cases, I really had to put the finger to my forehead and stop to think - am I really going to work eight hours over something that will save forty users five minutes a year?