>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.

>
>>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.