I appreciate the feedback.

Just think if we had a SQL backend. Then we could use asynch fetching and fetch the rows as the user types.

You are right in this scenario there should be some additional filtering. They shouldn't have to see all the records. Nor do they really want to.

Unfortunately at this time all we really have budget for is a quick and dirty solution using filtered indexes and changing indexes on the fly.

>Hi Dan
>
>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.