Add my vote, Ben, even though I've been unaffected (so far).

People were getting proper (for them, and maybe adequate is a better word) results the old way and the VFP9 implementation is like using a sledgehammer to kill a mosquito.

cheers


>Hi Aleksey,
>
>A new SET command in VFP9 to keep compatibility is desirable (for example "Set QryCodePageSensitive On/Off"). Actually, setting EngineBehavior to 80 to keep the old query behavior functional is similar. We don't care in some cases questionable query results will be got since we are sure our existing code will get 100% what we want.
>
>In many cases it is difficult, if not impossible, for us to unify the codepage of existing DBFs. For examples,
>- applications are running on a 24x7 basis and tables are large and will take time to copy
>- tables are generated or being used by another applications in clients' machine and are to be processed by our VFP application.
>...and so on
>
>We (our company) have spent a lot of time to make CpDBF() of existing tables in client sites match CpCurrent() in an version upgrade of an application, which has a large installation base and are being run in both western and Asian countries. So far, we have not yet managed to solve all the problems. I hope a new SET command eliminating the codepage problems can be found in VFP9-SP1.
>
>
>Ben Tam
>
>
>>>>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