>Since I started this mess.....(lol)
>
>And this applies to native tables......
>
>SET FILTER is a crappy way to get a limited recordset. In the old days, SET FILTER was just plain sequential access to the records and could, therefore, be excruciatingly slow. Nowadays, it uses some optimization and is somewhat faster. Still is slow, though, and there are lotsa better ways to grab a subset of rows from a table.
>
>I have found one reason to use it. Consider a parent-child-grandchild relationship. A corporation has multiple operating companies. Each company has one or more divisions. Each division has one or more products. The relationship is:
>
>Corporation (superentity, only one)
>Company (Parent)
>Division (Child)
>Product (Grandchild)
>
>In a single edit session, you want the user to be able to edit a company and add/edit divisions and products at will. You also want all changes to be saved or reverted as required. How to do this? Well, you can't just use child and grandchild table buffers because, if in the edit session the child record pointer is moved, you would normally need to requery the grandchild. This does not work with uncommitted changes in the grandchild.
>
>So, what I have done in these cases is buffer the entire products table and SET FILTER to those products matching the division key. It's the only way to maintain a single-edit paradigm under these circumstances.
>
>(and, no, I don't take kindly to drill-down edit structures....you should edit everything about an entity with one edit session)

Couldn't this be done with a SET RELATION TO and/or SET SKIP TO [with the table buffering]? IMO, I would have the user commit or revert changes when the Division or Company is changed.

How would you do this if the backend was SQL Server or Oracle? Even when I use VFP as the backend, I have started asking myself this question and design that way [just in case the project eventually ends up as C/S].