Hi Sergey,
>>Conclusion:
only way to use variable ORDER BY clauses is by using macro expansion.
>
>Yes.
>
>>However, this totally blocks SELECT syntax checking at compile time and thus decreases my development speed a lot.
>>
>>Am I right ?
>
>You're right that ORDER BY clause will be validated at runtime but I don't uderstand how it affects you development speed, whatever it is.
Well there probably becomes a need to carefully edit the content of the memvar before expansion, just to make sure it is 'clean'.
Jim
>
>>
>>>Hy Andrus,
>>>
>>>I have no more knowledge about internals of VFP than you do. I can only speculate how it works based on my expirience.
>>>
>>>
>1. If numeric expression works, why the following code will not work:
>>>>norder = 1
>>>>CREATE CURSOR test ( test c(1) )
>>>>SELECT * from test ORDER BY 0+norder
>>>>Result: SQL: ORDER BY clause is invalid Why ?>>>
>>>It seems that foxpro decides if value in ORDER BY clause is numeric expression or column name based on the first two characters. If the first character is a digit or the first chatacter is +/- sign and the second character is a digit than it's numeric expression. Otherwise it's a column name. For the numeric expression foxpro expects only numbers and operators +,-,*,/. Anything else will generate an error. The ORDER BY clause '0+norder' from your example above is invalid from foxpro point of view.
>>>
>>>
>2. If I'm using name expression why the following code will not work:
>>>>CREATE CURSOR test ( test c(1) )
>>>>SELECT * from test ORDER BY ('test')
>>>>Result: SQL: Column '' not found error. Why ?>>>
>>>Foxpro doesn't expect name expression in Group By clause. As I explained above if it's not a numeric expression than it's column name.
>>>
>>>< snip >
>>>
>>>The bottom line, that's the way foxpro parses ORDER BY clause now. Theoreticaly, it could be changed in the future versions of foxpro and both your examples could became valid.