No, you do your own testing. It is not the SET EXACT but the SET ANSI that effects the SQL Selects, the SET EXACT is a logical preference, as if I do a SEEK I want an exact match not a generic match, if I want a generic I will SET EXACT OFF and set it back on after I am finished.

I think that the VFP default being SET EXACT OFF is one of the the most confusing defaults I have ever seen.


>>Hi,
>>I was just stating my findings, it would appear that the "==" is evaluated on each iteration, whereas the SET EXACT & SET ANSI are not.
>>
>>Do some tests yourself, create a dbf with 15mil + records and a number of keys, create several keys based on integer, character & binary fields and see what your findings are. Conservatively it gives a 10% difference in timings, remember to reboot the workstation between tests to get reliable results.
>
>Well as Jim Booth points out == is not the same as SET EXACT, there is the issue of comparing apples to apples. It's your claim, demonstrate it. You've already written the code.
>
>>
>>>>Hi,
>>>>I have recently done some performance testing on large datasets in VFP9, as result we are now using SET EXACT ON & SET ANSI ON and not using "==" as it does have a perceivable impact on performance when processing large amounts of data.
>>>
>>>When a scientist wants to make such a claim in a journal they must provide evidence and practices which others can duplicate. Are we not doing computer science? IOW would you please prove that?
>>>
>>>>
>>>>>Good Friday Morning to All,
>>>>>
>>>>>I ran into a problem using <> operator where the following happens:
>>>>>

>>>>>cTest1 = "This is a sample string"
>>>>>cTest2 = "This is a sample string test"
>>>>>? cTest2 <> cTest1  && returns .F.
>>>>>

>>>>>
>>>>>Now I am thinking if I should do away with using <> operator because it always relies on SET EXACT ON and just use "==" in ALL my comparisons. What do you think?
>>>>>
>>>>>Thank you.