Nancy,

>> 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.

In general my applications don't have to scale, If they have to I might find out where performance problems *CAN* occur and take the appropriate steps to solve it. There is an awfull lot in software world that doesn't scale. Let's take for example all those questions about combo and listboxes that contain more than a few hundred items. They certainly don't scale. Did you ever used a combo for lookuptables ? If not I think you should reconsider your UI. Comboboxes server perfectly for less than 100 items (like the number of states in america).

Access applications don't scale well either.

Im my case *ONLY* the combination of a large tables with a user defined filter with a high selectivity don't scale. I can easely identify those cases and take appropriate steps like:

- Preventing filtering on fields which cause performance problems.
- notify the user that the action he/she is going to take may take a while to complete.

>>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.

Mis-using features is quite common. Let's take for example defining an article for only adding a comment to an invoice line. This is mis-use of a feature. The ordering system should provide means to add comments to and invoice line. If a user mis-uses the filter feature because he/she regulary want to list particular items for a certain purpose, you might want to consider another mechanism to provide the same.


>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.

You seem to have your opinion about that and seem to be comfortable with it. I'm not. I really think I'm missing functionality when this command disappears.

>>- 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.

So, using p-views is limiting your development. If for whatever reasons you might want to use Locking of records in buffermode - none, you've to find a workarround.

>>- 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?

WITH set filter you're working on the table directly, with p-views you've got to commit the canges first, again limiting development.

>>- 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.

With set filter you can easely use existing indexes for relations and setting order. With p-views you've got to create them yourself giving performance problems and can't be used within transactions.

>>- 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.

No it won't. Only in a few specific circumstance it will. P-views will generally generate performance problems if the resultset contains more than 1000 items and up, SET FILTER doesn't unless it is not rushmore optimizable or using in a grid with high selectivity. I'd say these circumstances are more exceptions to me than a general rule.

>>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.

I simply disagree with this. It's not as far as flexible as SET FILTER. it might perform better in certain circumstances, but in others SET FILTER wins.

>>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.

See previous reply,

Walter,