That doesn't matter. I'm using turkish Windows and can test for our arabic/russian countries. Also turkish alphabet some extra letters than you (ı,İ,ç,Ç,ö,Ö,ğ,Ğ) and we can use US Windows with this way.

>But are they using Russian / Arabic Windows? If so fine, but not if they are using US Windows.
>
>>Really? :)
>>
>>We have customers at old russian and arabic countries and worked at all of them...
>>
>>>That will not work. Non-unicode code page is not relevant to VFP, only to screen display.
>>>
>>>>>>i am trying to enter russian characters into my table,
>>>>>>
>>>>>>i have given the command
>>>>>>
>>>>>>codepage=1250 in config.fpw
>>>>>
>>>>>That's central european set, i.e. latin with šđčćžöüóúőpŁłéáű etc. For cyrillic, the codepage is 1251.
>>>>>
>>>>>>and in my startup main program
>>>>>>
>>>>>>

>>>>>>set collate="RUSSIAN"
>>>>>>

>>>>>
>>>>>Don't. Collation should be set for certain indexes individually, where you need them - on names etc - not on numeric or date fields. Probably can't be done anyway. Indexing a non-character field on anything but machine sequence is, if not impossible, leading to errors.
>>>>>
>>>>>>but i still get ???? instead of the russian characters
>>>>>
>>>>>Get it where? You should be able to set the .FontCharSet for any control, including _screen. Mind you, this does not include form captions, as they are governed by the current machine's character set for non-unicode programs, which is set somewhere in the control panel, regional settings or some such, depending on your version of windows. If there's a mismatch there, you'll get question marks or all accented characters (because the cyrillic set is, in cp1251, all in the upper half, which maps to these accented things in other codepages).
>>>>
>>>>codepage=auto
>>>>he can use set collate, delete and regenerate indexes is not a big deal. but his problem is not about these, he just should choose nonunicode programs language from control panel.