The SET ORDER TO nIndexNumber variant of the command allows to set index by tag number. What is not documented in the help, that nIndexNumber could be a variable or field name. That what you see in your case. It'll work w/o errors as long as numeric value in the field corresponds to an existing tag # or 0.

>
>Has anyone run into this?
>
>Right or wrong, I have always used the following syntax when setting the ORDER of an index:
>
>SET ORDER TO TagName && Where TagName is the name of the Tag
>
>Or...
>
>SET ORDER TO TAG TagName
>
>Recently we had an error that popped up when an index on a numeric field was deleted. The name of the index was the same as the name of a numeric field in the table. There was no error message and the index was set to the first index. I finally realized, after some head banging that if the TAG doesn’t exist VFP tries to help you out by attempting to EVALUATE the tag name that you supplied. So, in our example since the field evaluated to a valid index number (1), it was using that value as a TAG Number and set the order accordingly. If the number in the field had been greater than the number of index TAGs, in this case > 8, VFP would dutifully return an error saying that the index tag didn’t exist.
>
>The simplest solution to this is to ALWAYS surround TAG Names with quotes as in the following example:
>
>SET ORDER TO “TagName”
>
>Or...
>
>SET ORDER TO TAG “TagName”
>
>Since I have never run into this before I am wondering if this is new behavior in VFP 9?
>
>Is it just me or is the VFP help file wrong on this? Notice that TagName is not prefixed by a lower case “c”. Compare it to cTableAlias.
>
>SET ORDER TO [nIndexNumber | IDXIndexFileName | [TAG] TagName
> [OF CDXFileName] [IN nWorkArea | cTableAlias]
> [ASCENDING | DESCENDING]]
>
>Thanks,
>
>Steve