I do a lot of work with database structures with simple series of one-to-many parent-child tables like:

Room > Shelf > Box > Item

Let's say I want to allow a user to print out a report that inventories the entire contents of their storage facility, which contains several rooms, etc. (Each Item is in a box on a shelf in a room).

I'm finding that my head is spinning a bit with several ways of accessing parent-child data.

Should I be creating a List (Field) function on each table that returns a nice list of its child records that can in turn be combined in a List (Field) calc on the next-higher level?

Or should I be creating a multi-part layout with leading and sub summaries to stack up the 4 tables? (And would I put that in the context of the Item level, or the Room level?)

Or should I be doing some sort of fancy portal-within-a-portal layout that I've never tried before?

I'm kinda thinking the series of List functions would be cleanest -- but maybe I'm just shying away from the whole multi-part reporting thing, which I've done before but always seem to give me a headache puzzling it out. . ..

Suggestions?

Albert

Edited September 23, 200916 yr by Guest

The simplest (and the cheapest, in terms of required resources) way is to produce a report from the Items table, with 3 sub-summary parts.

Ah -- very good, I'm on the way now, working fine.