As I correctly understood, you would like to have different behaviors for VFP's functions in different SELECT-SQL clauses.

Wouldn't it be just another difference that would have to be documented (see the thread about VFP's docs :)) and understood by the users?

Vlad

>Arnon,
>
>I would agree for a "user" function. But surely VFP can make some assumptions regarding its own functions. It was precisely the though of crossing midnight which prompted my original response, specilating that the SQL constructor would not want to get different results based soley on what time the query ran.
>
>VFP's SQL *can* make assumptions when it comes to other factors, so it does not seem out of the realm to me that it would be able to do so here. But I wholly agree as regards "user" functions.
>
>Cheers (and I *do* consider myself corrected, by both you and Vlad),
>Jim N
>
>>how can the SELECT know that a function included does not change its value
>>(it is after all a function call)
>>and though usually DATE() shouldn't change during the query (btw as Paul
>>stated what happens if you run the query very close to midnight..)
>>I don't think it is stupid to re-evaluate them
>>
>>Arnon
>>
>>
>>>George,
>>>
>>>Pardon my English, but that would be awfully stupid of SQL - to run the
>>>Date function for every record in the input. What makes you so sure it
>>>would do so??
>>>
>>>Enquiring minds need to know.
>>>
>>>regards,
>>>Jim N
>>>
>>>>>Is there any optimization difference in the following:
>>>>>
>>>>>SELECT FIELD FROM TABLE WHERE FIELDDATE=DATE() INTO CURSOR TEMP
>>>>>
>>>>>OR
>>>>>
>>>>>ldDate=DATE()
>>>>>SELECT FIELD FROM TABLE WHERE FIELDDATE=ldDate INTO CURSOR TEMP
>>>>
>>>>Michel,
>>>>
>>>>I'm not sure about differences in optimization, but the latter query
>>>should execute faster. The reason being that the date function will have to
>>>be called and it will have to return its value for every record in the
>>>table. In the latter case, it simply a straight comparison.
>>>>
>>>>George
>>>