>Bob,
>
>>> No... I don't think so... remember, the parameters only come in when you a querying the back end. <<
>
>Perhaps I don't understand your answer. As I understand it, you are suggesting a child view param'd to the parent, and a filtered grandchild. Well, if I'm filtering the grandchild to the child, isn't it because I have all records relating to the top-level parent? And don't I get them by param'ing the view to the top-level parent, instead of to the child (it's own immediate parent)? It seems to me that this is what you are suggesting, please correct me if I'm wrong.
>
>It's this idea of param'ing the view to any level other than it's own immediate parent that really blows up when you are seeking the general solution.

I actually came up with a possible n-level generalizable solution. But I ran into stuff in VFP that kept me from using it in practice, and went back to making cursors directly on vfp tables, and using cursors without worrying about views. My unsuccessdful generalizable solution was as follows:

The grandchild query went something like this.

Select * from grandchild where childkey in (select childkey from child where parentkey=parent.parentkey)

A greatgreatgrandchild query would have been something like:

select * from greatgrandchile where grandchildkey in (select grandchildkey from grandchild where childkey in (select childkey from child where parentkey=parent.parentkey).

You then use filters as previously suggested to limit which records the user sees.

Of course even the first query is too complex for the view designer, so you have to use cursorsetprop to make the view updatable. Also it is not really generalizable because VFP limits the number of subqueries allowed. And I also found that when I inserted new records with appropriate child and grandchild keys VFP would add the records, but blank the child keys at commit time. Since I'm using native VFP tables, I simply gave up on updateable views and went back to optimizable filters against cursors -- faster, less trouble, and easier to write and maintain. Yes, I know this makes upsizing ten times more difficult -- but the project I'm working on has an 18 to 36 month life cycle at which time it is due to be replaced rather than upgraded.

Incidentally, the relate directly to the parent table is not as bad as it sounds. The queries become simple again. The filter is always against the level immediately above it, so the parent key is the only extranous foreign key needed. That is a great-great-great-great-great grandchild would need (in addition to it's own primary key) only the key of the great-great-great-great grandchild (which it would need anyway for relational integrity), and parent, without requiring any intermediate -- since the save would take place only on save of the parent. That is you actually have a clean n-generalizable solution -- clean except that you take the step of denormalizing your data just to the extent of propagating the parent key through all sub levels, no matter how far down. This is often done to speed up reporting and querying in any case.

Bear in mind that you engage in some denormalization every time you build an address with address line 1 and address line 2 in it. Heck, when you do that you are logically (though not physically) violating 1NF. I'm tired and rambling a bit -- but hope some of these comments advance the discussion.