Hi Dan

>I've never used the SET KEY. I'm going to look into that.
>One problem with the concatenated index is that there is a drop down that allows the user to select which office to view in this finder. The drop down has an "ALL" selection which would show all the records. If you put the office at the front of the index it would be difficult to handle the all selection.

That's the drawback to techniques that don't use SQL. You have to provide enough indexes and/or enough code to handle all the combinations of filters and re-ordering. That is made even more difficult by having related tables.
The minute someone wants to "filter" by combinations of fields and order by combinations of columns, SET KEY becomes harder and harder to manage.

Seriously, does anyone need to see all orders? You can use SQL. You can improve performance by returning only the rows (and columns!!!!) the user needs to see. You index the resulting cursor to allow the reordering they're after.

At least in this case, you only have to provide two sets of indexes. One has the office in front for the office filter. The ALL is not difficult. In fact, you need not do anything to handle the ALL filter! Add another set of indexes that has no company id concatenation. SET KEY TO without any other arguments would show all orders for all offices.

You'd SET ORDER TO the tag that supports the current filter and order. Then you'd SET KEY to the filter or nothing.

It should be a piece of cake for this scenario.