>>Hi Aleksey,
>>
>>Perhaps, it is not a bug from your point of view. But it is a big limitation in the work with tables that have different code pages. My application worked great with VFP8. It got slow twenty times after rebuilding with VFP9. There was not easy to explain my users: It is not a bug; it is only the new version of the development tool. I don't understand why the behavior of optimization is not under the developer control in this case, as is in many other similar cases.
>>
>>
>>Ladislav

>Hi Ladislav,

>Could you be more specific? What are the other similar cases?

>Thanks,
>Aleksey

Hi Aleksey,

Thank you for your interest. I try to explain what I mean, but my English in not perfect, sorry.

There are a lot of commands only for compatibility with previous versions in VFP and also there are some settings that give possibility to change default behavior of some functions. I mean for instance

SET ENGINEBEHAVIOR...
SET REPORTBEHAVIOR...
SET COMPATIBLE...
SET NOCPTRANS...
SET OPTIMIZE ON/OFF
and so on

But If I want to use SQL SELECT command from DBF with codepage different then CPCurrent, I have no possibility to say "SET OPTIMIZE ON". In my case, I use only the surrogate keys as index expressions that consists of digits or English capitals. I suppose that is not problem to use such index expressions for optimization. I had not any problem with SQL SELECT using such index expressions for the optimization in previous versions VFP.

Sincerely,
Ladislav