Nancy,

>> It's true that this *CAN* be slow, but that's the problem of the users, He/she either get's it slow or not at all.
>
>I must say that this kind of expressed attitude towards users really raises my hackles. I have to assume you don't mean to be so cavelier and that it's just the inadequacies of this medium.

Nancy, I admit that this statement was a bit abbrasive, but all my applications are optimized for the most common things users do. 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. Since I use the filter for easely browsing trough data in a grid (think of a BROWSE FOR... ), some users may find performance dropping down. But again the filtering feature is an add on that was not in the product before. So they've got an extra feature that *CAN* be slow in some circumstances. Because I think they'll use them in exceptional cases (only advanced users) where there is only a small chance that performance will significantly drops down, I don't have any problems with that.

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.


>There are most certainly ways to give this functionality to users in a functional form. It takes more coding, that's for sure. SET FILTER is only useful from a programmers POV since it's so easy to code. But since the programmers convenience isn't worth diddly, it's like a person being born with a tail.

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:
- P-views can't use buffermodes none and pessimistic row and table buffering
- You can't refresh the p-view when you've got modifications in the view.
- 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.
- P-views generates a temp table, consuming CPU cycles, disk I/O and memory, giving serious performance problems with larger tables.

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.

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

Walter,