George,

>>>This is very similar to what must occur when using a function such as MIN() in an SQL statement. Only by comparing each row to the current minimum can the function determine the minimum value. This will result in the number of rows examined number of comparisons.
>>>
>>>This is pure computer science, part of which involves the calculation of computational complexity. How much additional is required, in terms of the amount of time consumed is the only question involved, not that this will incur greater processing overhead.
>>>
>>>There's no argument here to the contrary, Walter. This is what happens.
>>
>>Well I think you're jumping to conclusions, George, and probably erroneously in this case.
>>
>>I seriously doubt that MIN() is a "function" in the traditional sense. I notice, for instance, that the Help calls it a "field function".
>>I can't think of a regular VFP function that isn't 'self-contained' - working only with arguments passed or possibly data from the active record of an alias.
>>It would be my **guess** that MIN() is more of an internal 'flag' that later causes some additional processing. At the very least I'd bet that you can't equate any regular function with VFP's SQL-specific 'field functions'.
>>I'd also guess that there **is** extra overhead, but also that it is very low comparably.
>
>MIN() would be a function in the true sense of the word if it received a parameter and returned a value. In this case, it results in the smallest value of those it's received. Therefore, each field has to be examined and compared, internally in this instance. Regardless of how one equates them, it is, nonetheless, a function.

It is only intepretated ones....

Walter,