Walter-

>>> It's true that this *CAN* be slow, but that's the problem of the users,
>Nancy, I admit that this statement was a bit abbrasive,

Yes, it was, and while it may seem like quibbling, IMNSHO, it is always a mistake for programmers to ever take this position.

> Using a simple filter on a (main) table of about 10.000 (seldom they're larger than that) or less does generally not give any real performance trouble at all.

Well, that's cool and why you get a away with using the technique. But it won't scale well. Guaranteed.

>If users mis-use this feature for other purposes (and thus more frequently), I might want to find an alternative to that because I believe that then this is a design issue.

I'm sorry, but again, _using_ a feature more than the programmer thought it would be used is not misusing it.

>I've seen arguments about using p-views here, but I've got serious problems with that. P-views cannot replace all functionality of SET FILTER:

Well, again, all I can say is I never used SET FILTER but once in 12 years of coding. I still say you use it as a programmer because it is convenient from a programmer's POV. Again, I think the programmer's convenience is the least most important element of a development project.

>- P-views can't use buffermodes none and pessimistic row and table buffering

So? I don't know why you'd want to use buffermodes = none, and you can program so that the effect of pessimistic buffering is achieved.

>- You can't refresh the p-view when you've got modifications in the view.

Again, why is this a problem as it relates to set filter?

>- You can't use the original indexes of the source table. Though you're able to create temp indexes, they'll give a problem within transactions.

Huh? I don't understand this point at all.

>- P-views generates a temp table, consuming CPU cycles, disk I/O and memory, giving serious performance problems with larger tables.

You've already said you don't use larger tables, and that is why SET FILTER doesn't cream your application. If you use larger tables, your SET FILTER will.

>Another alternative might be the SET KEY command. but this also have disadvantages:
>- You must use a specific index order.
>- You've got to have an index for each expression you want to filter on.

It's better than using set filter.

>Since, my applications don't have large main tables I've never had any client complaining about performance trouble with this feature.

See previous comments about scalability.