Hi Beth,
Pardon me for jumping in, but you state that you are setting the relationship for the Grandparent and parent. Are you using SET RELATION ... ADDITIVE? If not, SET RELATION without ADDITIVE will break all other relationships in the current workarea.

-mike

>Great. My relationships are defined in the DE, with parent going to child. And when I bring in the grandparent, I set that relationship as you discribe. Everything you talk about here, I have done, which is why I am so lost and confused.
> The relations in the DE go from the parent to the child, and they are 1 to many.
>
> My grandparent table takes over the grid the parent uses, so the parent does not have a grid, but has textboxes. If I click on that grid, the textboxes change to show the data for the current record on the parent.
>
> I do not do a filter on the on the parent table, because I do not know how to set the filter because the grandparent is the result of a report query off of all the table in the db, not just the parent table Customer. But the result set always has the customer_id in it, so that I can set this relationship up.
>
>Thanks for your adivise on this.
>Beth
>>OK
>>
>>Are the persistent rel's exhibited in the DE? And which way do they go? i.e. is it address(1) -> customer(m), or 1-1 or what? Whichever you want the rel to go Customer->address/contacts. If the rel's in the DE go the other way (e.g. One address/contact can do for many customers) then you want to delete the rel in the DE (this will not affect the persistent rel in the dbc).
>>If the above, or the rel's aren't in the DE, then draw rel's in the DE, taking the customer PK, "Customer_ID" to the related FK in the "child" table. This is effectively making the so-called child tables, well, child tables.
>>
>>Bear with me :-)
>>
>>Your static text box fields, sourced to their respective table fields, yes?
>>
>>OK, moving the rec ptr in the customer grid SHOULD now get the related rows in the "child" tables, and thus the static fields in the text boxes, without any code.
>>
>>When you add the filtercustomer table, do you do a "set relation into ..." to your customer table?. If not, try it. I don't quite understand whether this is a sub-set cursor of the customer table (i.e. structurally identical), or why you don't just do a filter on the cust. table. Has this "grandparent" got its own grid.
>>
>>Anyway, there's some ideas. Without a better mental picture of your set-up it's hard to advise further
>>
>>hth
>>
>>Terry
>>
>>>Hi, Terry
>>> They are Dbc tables, but the grandparent table is loaded by me in the init of the form.
>>>>Beth
>>>>
>>>>Are they dbc tables, featured in the DE, or made-to-measure cursors?
>>>>
>>>>
>>>>>Hi all
>>>>>
>>>>>I have a form with several different grids on it, each on their own page. Each grid has a different recordsource, but the cursors are all related. There is the parent table – Customers, and serveral child tables – Addresses and Contacts. Everything works okay until the user wants to work with a smaller data set. I add a Grandparent Table – FilterCustomer which limits the Customer table. When I do this, the two child tables refuse to work correctly. I have put code into the click and activate method of the pages trying to get this to work. The code was:
>>>>>

>>>>>local lcAlias, lcCust
>>>>>lcAlias = ALIAS()
>>>>>lcCust = Customer.custmer_id
>>>>>SELECT 'Customer'
>>>>>LOCATE FOR custmer_id = lcCust
>>>>>SELECT 'addresses'
>>>>>LOCATE FOR custmer_id = lcCust
>>>>>SELECT (lcAlias)
>>>>>

>>>>>This will get the text boxes on those pages to show the correct info, but the grids are not correct. And as soon as I click on a cell in the grids, the textboxes are incorrect.
>>>>>
>>>>>Can someone help me here?
>>>>>
>>>>>I am using the basic VFP Forms and buttonset.
>>>>>
>>>>>Thanks,
>>>>>Beth