David,

The index wouldn't have to be maintained. It would be a one shot only thing. To put the Ascending and Descending records in groups, though, would require code to find the beginning and end of each group and then fill it in. In my case that code alone would do the trick and the index would then be superfluous. The code only solution, the way I see it, would be to INDEX ASCENDING and then go through the records using SKIP 1 while the indicator field is "A" and, when I encounter a "D", run through the table with a SKIP 1 until I hit an "A" again and then process those "D" records using a SKIP -1 until I hit "A" again, etc., etc.

I figured that this would all be pretty slow on a large table especially if the groups of A and D records were relatively small. I was hoping that I was overlooking a INDEX or SQL solution that would make things, if not easier, at least faster.

Thanks, I believe Plan B will have to be it.

Ed

>Edmond,
>
>>I'm trying to create an index that will internally change back and forth between Ascending and Descending depending on the value of a field.
>
>Ed Rauh's response is the "key" to your problem *IF* you don't need this to be a dynamically maintained index which is kept up to date with every addition or change to the table. Well, actually, you could handle it even in those circumstances with some logic on the save that determines which group of keys the current entry fits into at that moment in time.
>
>There is, however, no way I can see to do it just in the index tag -- you must have an additional field in the table that indicates which group of records this record is part of. Let's call that field cGroup.
>
>cGroup will contain for each record the lowest cValue of the group that record is part of:

cGroup  cValue	AorD
>01      01      A
>01      02      A
>03      03      D
>03      04      D
>05      05      A
>05      06      A
>07      07      D
>07      08      D

>
>With that done, your index could be

INDEX ON cGroup + ;
>IIF(AorD="A", STR(VAL(cValue),2), STR(0-VAL(cValue),2));
>TAG SomeName

In the case of "D", the negative value of cValue will order those records in reverse.
>
>When adding or updating, you would search the existing ranges of records to determine the value to store in cGroup, and would obviously need logic to insure that cGroup is *always* recalculated during any change to cValue or AorD fields, perhaps for the entire group if the lowest value changed.
>
>It's much simpler if you can just run a routine against the table periodically -- just prior to running a report, for instance -- instead of keeping it dynamically updated.