>If this is in the wrong conf, please point me to the correct one. Thanks!
>
>A client has a huge Clipper app (6.5 MB of source code) they want to port directly to VFP. No new screens. Just a port. Most of the code, amazingly, has ported. However I just ran into a brick wall.
>
>The Clipper app makes extensive use of the the DESCEND() function which does not exist in the same form in VFP. I badly need to reinvent it.
>
>In Clipper you can
>
>INDEX ON fld1 + descend( str(fld2, 7,2) )
>
>giving
>
>fld1 fld2
>-----------
>111 zzz
>222 yyy
>333 xxx
>
>This gives a different result than using the Foxpro DESCENDING clause with INDEX ON.
>
>Virually all the fields in this app using DESCEND() are character conversions of numerics. They have to be character because they are part of multi-field index keys.
>
>I've actually managed to re-invent a DESCEND() on character fields that works, but the performance hit is substantial. Anyone have ideas how to do this?
>
>PS I could do something dreadful like
>
>INDEX ON fld1 + descend( str(10000-fld2, 7,2) ) + fld3
>
>but would rather not.

If it is numbers only, the above seems quite appropriate (without the descend() function). For example, assuming Fld2 is a number, but saved as character:

INDEX ON Fld1 + str(-val(Fld2), 8, 2) + Fld3

Otherwise, if there are other characters involved, you will have to create your own descend() function, which will pressummably replace very byte with the character that has the ASCII value 255 - byte.

The performance problem should only appear when you create the index for the first time, or do extensive changes (like REPLACE ALL...). I don't think you will notice a performance problem if the user just changes a single record.