Hi Dan

As Craig and Fred have said, you'd be better off with SQL. Rather than showing all records for either company, you'd have the user specify something else. Date range for the orders would be useful to reduce the set.

In the meantime, you could build your indexes by prefacing them with the company like this...

INDEX ON STR(CompanyID,10) + STR(OrderID,10)

Then you can use SET KEY instead of SET FILTER.

When the user first accesses the form you do this...

lcCompanyID = STR(currentcompany,10)
SET KEY TO &lcCompanyID, &lcCompanyID

I think that as long as each column has the company first, you'd be able to switch the order and GO TOP to see the grid in that new order. I think you won't have to SET KEY TO again.

HTH

>VFP 8 - Windows 2000
>
>We've got a generic finder which has a grid with possible selections that allows the user to change orders on the fly. Each order that the user can select has a corresponding index in the table.
>
>We're using this finder in a simple order-entry application.
>
>We have added an office to their underlying data design because the client is just now opening a new office and needs to handle ordering from each office.
>
>We have a couple tables with more than 150,000 records.
>
>In the finder we need to add a "filter" for that office so that the user sees only the records for that corresponding office.
>
>The problem is that this is very fast for the primary office but very slow for the secondary office which has very few records.
>
>Right now the code looks something like this:
>
>** Set the office filter
>** Issue a Locate
>** Refresh the grid.
>
>The refresh of the grid is very slow.
>
>There are a couple of solutions I can think of, none of which I like.
>
>1. I can add filtered indexes for each of the above offices. This is messy and would require a change of indexes on the fly.
>
>2. I could add a filtered index with reference to a variable. This would mean that the table couldn't be open without first setting the variable.

It would really mean you'd have to rebuild the indexes after setting the variable.

>
>Having two separate databases for the different offices is out of the question at this point because we be too costly.
>
>Is there an elegant solution to this problem?