Hilmar,

>>>>A 'nooptimize' option per clause expression is a good idea too.
>>>
>>>I don't like the NOOPTIMIZE option: what I am striving for (in many cases) is PARTIAL optimization. No R.Optimization would mean that ALL RECORDS have to be retrieved, whereas Full R.O. would mean (in some cases) retrieving almost all INDEX KEYS. With Partial R.O., both things can be avoided. In some cases, at least.
>>
>>Am I misreading or misunderstanding???
>>
>>You don't like the idea of having the capability to say NOOPTIMIZE for a specific WHERE clause (or JOIN clause) expression?
>>Something like
>>SELECT. . . . WHERE ... AND Sex = m.ApplicantSex NOOPTIMIZE OR ...
>>would cause a problem? I must be missing something.
>>
>>JimN
>
>It is my understanding that the NOOPTIMIZE affects all conditions, not one particular condition (correct me if I am wrong here). If this is the case, all records have to be retrieved.
>
>With a partial optimization (optimizing the first condition - say, "ApplicationDate = ldDate", but not optimizing the Sex field), possibly only a few records would be retrieved.
>
>Hilmar.

Yes, I believe that, as currently operating, NOOPTIMIZE affects the entire SELECT statement.

But Dan suggested, and I thought it was a good idea, to add to VFP the capability to be able to explicitly tell VFP to NOOPTIMIZE any specific clause.

Your second statement seems also to agree with the benefit of this. Correct?

Cheers
JimN