This looks to me like it just alters the child tables - I think I've already accomplished that using tables that have persistent relationships, but most likely, I'm missing something here. I don't see how to create a parameterized view for the client table so it filters down to a list of clients who have emergency visits, for instance, on that first page. One thing I see as a possibility is, as you say, to create a series of views, but instead of for each child table, I would create them on the parent-client table each one inner-joined to a different child table. That would create the filtering I need. Then, I suppose I would programmatically change the grid's record source to the appropriate view based on the user's choice and refresh it. How, then, would I get the child tables on the ensuing pages to nicely respond to that? It looks like this is where your suggestion comes in where I create a parameterized view for each one and then programmatically refresh them after the user clicks on a client on the first page. This all seems so kludgy compared to the persistent relationships I already have set up for the tables...


>Diana,
>
>I'd use several views, basically one for each underlying child table. Assuming the child tables all have say iClientKey as their foreign keys into client you just set the filter tab in the view designer to EmergencyVisit.iClientKey = ?client.iPrimaryKeyField
>
>Whenever the value controlling the subset of the view changes you TableUpdate() it to save changes and then Requery( "EmergencyVisitView" )
>
>>I think that makes sense. However, I have very little experience with parameterized views and am wondering how I'm going to set up this view to change from all clients, to clients with rows in the emergency visit table to clients with rows in the legal activity table and back to clients. Also, I'm assuming I can treat the view just like the client table in my database and set persistant relationships so the other pages work so conveniently...