>>>>>Is it possible to have 2 related tables in a grid control? One table has a field containing agency codes, and another table contains the descriptor data (e.g., agency name) keyed by agency code. I tried to include fields from the 2 tables while in Grid Builder, however, it appears as if only one table can populate the Grid. Any ideas ... or do I need to go back to the good ole' Browse command?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Glenn
>>>>Glenn,
>>>>
>>>>The limitation you are seeing ias ht grid builder NOT the grid. Build your gird with the grid builder, then in the data environment for the fomr put your two tables and set the relationship between them. Now go to the grid and change its columncount to increase it by one. Drg the new column to the position you wnat it in and set the columns controlsource property to Alias.FieldName for the field you want rfrom the related table.
>>>
>>>This will work fine with one more add-in: sometimes grid 'refreshment' routine should include resetting of the relationship to properly reflect possible value changes in second table.
>>Another approach is to define a view of the relationship and set the controlsource to the view name. A requery() of the view will refresh the grid with the relationship intact (it's implicit in the view). If a subset of the related tables is need you can parameterize the view and create temporary public variables to drive the requery as follows
>>
>>public fromrange, torange
>>requery('theViewInQuestion')
>>release fromrange, torange
>>thisform.refresh()
>>
>>where the view would contain the following selection
>>field1 between ?fromRange,?toRange
>>
>>The view builder will help with the syntax and final SQL statement.
>>These can allow multiple tables to be related and sub-selected yet displayed (and updated/added to) in the form container
>>that holds the grid. We like view since we can switch to remote datasources without recoding.
>>
>>HTH
>>Gary
>
>I absolutely agree with your thoughts. The only thing to mention that sometimes 'quick' set relation will save time (for view 'data loading'). Surely, for complex functionality view is much preferred.
Right on Ed. You can also index the view on the fly and set filter(s). Allows alot of real fast view filtering once the underlying information is fetched.
Gary