Nancy,

>For the record, I was trained from the very beginning (using Clipper Summer '87) to no use filters. Period. Had nothing to do with C/S "stuff" as you call it. Indeed, I barely remembered there was a such a command when I started with Fox.

Within the other xBase language it was a pain to use filters, because they were unable to use existing indices to optimize. In a lot of the old clipper programs you would find a construction like this:

SELECT table
SET ORDER TO 1
SET FILTER to someexpression
GO TOP

DO WHILE .NOT. EOF()
...
...
SKIP
ENDO


I agree, this sure was a performancekiller. Within fox, this all changed because it now could optimize the set filter. The need for filters within fox decreased tremedously because you could define the scope of the command within a FOR clause. Still I'm convinced there is a place for SET FILTER is some circumstances. This practically means that you should think twice to use a SET FILTER command, and be aware of the advantages and disadvantages compare to the alternatives.

>When it was necessary to "filter" we would index on IIF( lcondition, 'B', 'A' ) + cfield, then we would seek "B" and go from there.

>Worked great on large (for then) data sets that users could build custom queries for. Clipper was *such* a hog it would have been impossible to to use SET FILTER.

Yep,

>IMHO, you can't go wrong NOT using filters, but you sure can go wrong using them.

I'm on the standpoint you can both go wrong using them or not. SET FILTER certainly has it's place.

Walter,