>SNIP
>
>Hi Ed,
>
>While I agree that a second field which is not a part of an index can occur in any order, there may still be something unusual here.
>
>Are we not told that say, for an index created in the (default) ascending order, a SET ORDER...DESCENDING will simply cause the index to be read in the reverse order?

Absolutely, but how equivalent nodes are traversed in the tree is not specified or guarenteed; there are several different traversal mechanisms, all of which are valid. If you want an index to perform in a specific way, write the index correctly; don't rely on side effects.

Of course, you're probably sure that this is another conspiracy on MS's part to destroy VFP and the minds of VFP programmers. If you want to delve into the details of how balanced b-trees are traversed, I'll be happy to suggest some reading materials, starting with Donald Knuth's Sorting and Searching.

If VFP and FPDOS had to function in exactly the same way, using exactly the same algorithms, we wouldn't have gained many of the performance benefits seen under VFP. Using a faster algorithm to tranverse a b-tree in accordance with the sortation rules for the index makes me feel warm and fuzzy inside - it shows that someone on the VFP data engine development team did their homework. Please don't waste my time whining that it doesn't behave the way you would like, when what it does is function exactly the way is's supposed to.

>That's how I read things, and if this is the case then how do the records become presented differently (or I guess I should say the same)?
>
>Cheers,
>
>Jim N
>
>>
>>It's not a bug; if the second field is not a part of the index expression, VFP doesn't consider it as a part of the index sequence, so the order can be completely random. If you need a key to order on both fields, then create an index that includes both fields in the index expression. All that happened with FPDOS is that you got lucky with the order that records were encountered or added to the file when creating or maintaining the tag; insert the records in a different order into the table, order have the records occur in a different physical order in the table, and the results you got wouldn't be reliably duplicated.