>From the Hacker's Guide on filtered indexes:
>
>However, any index that's filtered in this way is ignored by Rushmore when it attempts to optimize commands, so use these cautiously. (Don't be misled by the VFP 6 Help, which seems to imply that filtered tags are used by Rushmore. In fact, what it's really saying is that Rushmore will optimize the INDEX command itself if appropriate tags exist.)

Giving Hacker's Guide statement the benefit of the doubt, let me give you 2 scenarios:

TABLE_A has filtered index TYPEA FOR type = 'A'; TYPEB FOR type = 'B'
LVIEW_A is a view that extracts record from TABLE_A with filter condition of type = 'A'
LVIEW_B is a view that extracts record from TABLE_A with filter condition of type = 'B'

I have two forms: FORMA, FORMB

FORMA has a grid displaying records from table_A using DE. It has two buttons where button1 sets order to typeA and button2 sets order to typeB then Refreshes the form.

FORMB has a grid displaying records from LVIEW_A using DE. It has two buttons where button1 sets recordsource of the grid to LVIEW_A and button2 sets recordsource of the grid to LVIEW_B then execute REQUERY().

benchmark output using SECONDS().

1. FORMA loads .18 seconds while FORMB loads 1.75 seconds if FORMB's nodataonload =.F.
2. FORMB loads .56 seconds if FORMB's nodataonload = .T.
3. Clicking buttons in FORMA, it took only .01 seconds to display records while FORMB took 1.75 seconds.
4. To be fair with FORMB (the caused may of interchanging recordsource), I deleted LVIEW_B in the DE so that the grid has its recordsource upon loading (this time LVIEW_A only). But it has the same output.

TABLE_A contains 50,000 records where TYPE of 'A' have 25,000 records equal with Type of 'B'.

Question is: How would it then Hacker's Guide statement be justified as authentic and true with due respect to the authors?

There is a confusing statement here between MS and HG that needs to be clarified.

---

>I have to argue with you on this because we tried using views just to extract a few hundred records from over 1 million records and we compared it to filtered indexes. And the difference is significant. IMO, rushmore also applies to filtered indexes because the logic behind it is the same with FOR, SET FILTER etc. which are RUSHMORE enabled.