>>>>>>>>In my grid class I allow users to sort on up to 3 columns by clicking in the headers. I convert all the fields to characters in order to string them together. For example, the code might look something like:
>>>>>>>>INDEX ON CharField1+STR(NumField2) TAG temp
>>>>>>>>The problem is that if the numeric field contains negative numbers, they don't sort properly by value. How can I get the numbers to sort correctly and yet index on multiple fields?
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>
>>>>>>>Elyse,
>>>>>>>
>>>>>>>Try this:

INDEX ON CharField1 + BINTOC(NumField2) TAG temp

This will work, however, only if the numeric field has no decimal places.
>>>>>>
>>>>>>Thanks, but the numeric fields do have decimals.
>>>>>
>>>>>OK, I think we got it this time. Use BINTOC() and multiply the field value by 10 ^ n, where n equals the number of decimal places. The upper limit would be 9 decimal places (1 billion). Will this work?
>>>>
>>>>Bingo! This seems to work beautifully, and quite cleanly, too. Thanks to everyone who offered their suggestions.
>>>
>>>Terrific! This was one of those problems that was so interesting, I had to find a solution. However, as a side note, probably the upper limit to it is probably a numeric field that has a total length, excluding the decimal point of 10.
>>>
>>>Thanks for sticking with me.< s >
>>
>>George,
>>
>>Is upper(CharField)+padl(NumericField,Len(NumericField)) simpler? :)
>
>Nope, didn't work, sorry. Should be

upper(CharField)+padl(NumericField*10**Len(DecimalPart),Len(NumericField))

I don't think this works either, Nadya. Consider that the following will be the order of the value using the above:

 -10.123
  -1.123
  10.123
   1.123

I know that the last two look wrong, but the individual index expressions for the two are

? PADL(10.123 * 1000, 8) && 10123.00
? PADL(1.123 * 1000, 8) && 1123.000
* And
? PADL(10.123 * 1000, 8) > PADL(1.123 * 1000, 8) && Displays .F.

In short, I believe that my solution is the most efficient and produces the correct solution that meets the specified criteria.

Interestingly, Glenn's solution, while not quite meeting the criteria (the use of ABS() will destroy the natural order of the values. IOW. -1.1 will come after 1.0 unless I misread it) does provide an alternative. Simply

INDEX ON CharField + TRANSFORM(NumericField, "@L) TAG mytag

will actually produce the correct results. There are a couple of things here.

First, the "@L" parameter for TRANSFORM() isn't documented. The "L" function code from the old @...GET statement was used to show leading zeroes, and just happens to do the same with the TRANSFORM() function. Whether or not, since this behavior isn't documented for the function, this will continue, is unknown.

Second, the comparisons take longer because there are more characters to compare.

Third, more than three decimals places will cause the value to be truncated.