>And what about table fields like customer code that are entered by an user, they can include any characters and they can be often used in select statments.
>Users want to have possibility to order table in such order and want to have all rows in proper place not some of them in the end of a list.

Smacznego! (it's lunchtime, right?)
That's a border case. You may want to create two indexes on those, or just have a regular PK behind and use these for user's individual search, not in a Select statement. Or sacrifice some of the speed just to let the users have their way. I'd decide depending on the case. I usually keep my codes as numeric, left zeros padded strings, and filter out most of the others.

Besides, even in countries like ours, they are rarely using specific characters in such codes. I've never seen a Hungarian car with any diacriticals in the license plates, and their supermarkets are called ABC, not AÁB, which are gramatically first characters in their alphabet.

I actually have one case of mixed codes, and, well, I index it machine on some locations, and Czech on some others - and neither ones complain.

>PS. Maybe in VFP7 ther will be no Czech collatig sequence, like Polish that disapeared in VFP6 :-). (I have posted this 3 times to MS but till now It is not on the bug list. Maybe in MS opinion it is not a bug but a nice feature dedicated to lazy polish programmers.)

IMHO, I think MSFT should publish the structure of foxpro.int, and we'd do it better ourselves.