>George,
>
>>And Walter, adding unnecessary functions, such as MIN(), to an SQL statement unquestionably adds additional processing overhead. There's no question about it.
>
>That's a highly overrated statement. As you'd know, the performance of a SQL query is highly determined by the (file) I/O. Since both described VFP SQL statements will cause exactly the same amount of file I/O (because the same records have to be read from the database) there should not be much difference. I've not done any extensive testing, but it would not surprise me that in a production environment the difference is not noticable at all.
>
>To me this argument is total bogus, unless you can provide a real world example where it does make a significant difference.
>
>IMO, This falls in the same category of 'common wisdom' that macro substitution is slow compared to EVAL() or name expressions. Performance wise, the differences between those strategies are insignificant. However, in certain situations, macro substitution might be hell lot faster than at least the EVAL function.
>
Walter,

It's hardly "common wisdom". The function will have to be called for each tuple (row) involved. No if's and's or but's, in order to satisfy the design of the function. While not SQL, here're two snippets that, for purposes of demonatration, show what I mean.

* a_strings is an array containing
* a set of strings to be concatendated
* separated a carriage return, line feed pair
lnlast = ALEN(a_strings, 1)
lcresult = ""
FOR lni = 1 TO lnlast
  lcresult = lcresult + CHR(13) + CHR(10)
NEXT
* The second sample
* a_strings is an array containing
* a set of strings to be concatendated
* separated a carriage return, line feed pair
lccrlf = CHR(13) + CHR(10)
lnlast = ALEN(a_strings, 1)
lcresult = ""
FOR lni = 1 TO lnlast
  lcresult = lcresult + lccrlf
NEXT

The first example requires the number of interations times 2 function calls. This means that if the array is 1,000 elements in length, 2,000 calls to the CHR(). The second example will always require two calls to it.

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.