>hmmm.. I tend to use row-buffered tables for maintaining the main tables like (employee, articles, clients) etc. For one-to many relations I use table buffered p-views. Here I'm able to change all artibutes (including the data in the one-to-many relations) and could undo them simply. The user can browse freely within the main row-buffered table (within a grid), until they change some data regarding this entity. However I still do allow the user to filter the table on a custom expression. How would I do this since I can't requery the the main table if it is a p-view.

Walter,

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

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

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.

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.