Dan,

You've denormalized your data, which is fine for showing data on the component level (or for making a report), but then you want to use the same denormalized data for showing information at the line level.

Sounds like you need 3 grids - first one may have several records but it has the 1 top-level record selected. Second one has the 3 order-level records, and third has whatever component-level records go with the selected record in the order-level grid.

When the record pointer moves in the top-level grid the lower 2 are requeried and refreshed (third grid would default to showing the matching records for record #1 in grid 2).

I really think you may have chosen an impractical way of showing the data to the users.



>sorry for not being more detailed in my explanation. The Table in question(A) was created to combine data from 3 tables in SBT. The three table in sbt are the order level,line level,and a component level the order level would have one record, the line level could have ? (say 3 line items for that order),the component level could have ? (say 3 components that make up the item on the line). I combined the dat from all 3 tables int to (A) and ended up with 9 records. 3component levels for each line on the order.The order number is on each record as is the line no and so on. This worked great until I needed to present all levels to the users VIA a grid for each level. When on the order level or line level the grid will have 9 duplicate records showing. There should only be 1 on order and 3 on line. These are free tables. So I only wanted the unique key for presentation in the grid Unique is a no no. Thats why I was leaning towards having multiple table instead of one(A). Thanks