>>Yes, but my question was "where does Rushmore live?" Is it contained in the index files or is it mainly in the VFP runtime libraries or maybe in both. If it is the all in the index, then taking advantage of it from something like VFP.NET should be trivial. If not, it would be a huge and possibly impossible undertaking. And there might be some intellectual property and/or patent infingment implications as well, which would stop anyone from reverse-engineering it to another VFP -like implementation. However, with all these great, fast (and free!) database backends (Postgres, MySQL, Firebird) now available, this shouldn't be a big deal anyway.

@Pertti: Rushmore can use different types of indices, so it definitely does not live inside the index. But the compression used in cdx and idx helps a lot when the wire is the bottleneck.

>Rushmore "lives" in the VFP core, which is also a part of the runtime files. But it is not really "rocket science", it is only a set of algorithms which evaluate all available indexes and choose which, if any, indexes will speed up the search, and how to use these indexes optimally. I don't think it would be that difficult to duplicate this functionality?

Tore,

for the single table search I tend to agree - looking through the selection criteria to get find the best search criteria is probably standard by now (I had to build something like that way back in the eighties) but I don't think it is easy to fit such technology to SQL implementation. FPD opened up new ways to prebuild data for reporting and nowadays basically all biz layer selection I know of is done via SQL. VFP's strength is IMHO largely the automatic way most of the time a workable solution is found.

regards

thomas