Jim,

First off, this is my last reply, I'm going to get ready for last-years eve. Happy new-year in advance :-).

>First off I never row buffer anything, too much magic can happen. Everything is table buffered.

Well, i've got the situation under control, I'm pretty comfortable with using row-buffering for main-tables.

>Secondly, I can write a view in code without predetermining anything at all. Generate the SQL at runtime.

Try this for a 1,000,000 record (same argument you used). Since it's is the norm that the tables are NOT filtered, and they *can* filter them. Also these main tables seldom reach such amount of records. (most mid-sized companies don't have 1,000,000 clients, articles, employees)


>If the design of the UI requires that teh edited records be buffered independently of teh keys for teh records et then I use a view to get the PKs and related the view into the actual table (or another updatable view) and let the editing go on in the other table.

This sure can be an alternative, though it's harder to implement and can't apply filters when the changes are not commited yet. (BTW do I see you proposing the use of a set relation ?)

>As for gird, well open a 1,000,000 records tabel adn tehn st filter to anything you like (even optimizable) and then see how "fast" your grid is. Grids and filters do not mix well together.

It still depends on the selectivity of the filter. If only a few rows are going to be displayed, yep, you've got a performance problem. But if you want to display all 1,000,000 records, p-views are definitely not an attractive alternative. Since the UI design says that all rows must be accesable at default, SET FILTER is the better choice.

Walter,