>>First, unless you're supporting Windows 3.1, I'd recommend upgrading to 5.0 as fast as possible. VFP 3.0 is a little buggier than one would like.
>
>We are still stuck with Win 3.1 due to older PCs :-(

I'm sorry... :)

>>Can you give us some sense of the resulting data structure? I find myself assuming there's one driving parent table, in which case it's at worst a long SELECT,
>
>Ok, here's one needed form:
>
>- text box listing an agency/company name from the Agency table
>- grid with columns containing (for that specific agency/company) my position, first name, middle, last, phone, email fields.

Ok, the basic structure would be Agency as driver (I don't want to say Parent as such, for reasons that I'll clarify later) and Person as the basis of your view.

>I have a Position table containing the Position Name, and a Person table containing the remaining fields. These two have a many-to-many relationship, thus a Contacts table exists containing the corresponding Position code and Person code for a specific position/person relationship.
It may be many to many, but at any given moment, it's one to many from either side.

>I also need the Agency Code from the Person table to filter only the Positions/People for the Agency listed in the text box at the "moment". Ideally I wanted a view with all of my fields needed for the grid which would be a Child of the Agency (Parent) table used in the text box. The "Next" button would change to the next Agency and thus refresh the grid with that Agency's contacts. I just can't seem to make the View a Child since I can't get an index on it. I keep thinking I'm missing something here, but think I'm too close to it at the moment to see it :-(.

What I would suggest is a parameterized view, taking the Agency Code as the parameter. When you change agencies (incidentally, a combo box would be a nifty way to select agencies, rather than a previous/next button set) you would take the new value of Agency Code and requery the view, which would change the contents of your grid. Thus, there would be no need to create a formal relationship between the Agency table and the Person table (which is why I said that the were not in a strict Parent/Child relationship). All the other lookups can be set in your view definition.

Make sense?