Hi John,
I would love to take your advice but I am a real novice at this stuff and to
be honest I have no idea what you are talking about or how to do what you are
asking. I don't even know where to start. I tried the manual and help but
still came up blank.Maybe I could email you the file so you could see what I
am trying to acheive and maybe very quickly help me out?
Thanks
JohnG
Well... I'm a self-employed database design consultant. What you're suggesting
is what I do for a living; it's a bit beyond what I'm comfortable offering as
a free service. If you're interested in hiring me, let me know by email and
I'll send you my terms.
My suggestion was that you restructure your table. A "Pack" of lumber consists
of multiple Boards, each board with a length, a width, and a thickness...
right? You're correctly storing the width and the thickness in fields with
those names, storing numeric values. The fact that you have a separate FIELD
for each length is the source of your problem!
You have a One (pack) to Many (board) relationship. Rather than handling that
one to many relationship as a spreadsheet - many fields within a single record
- consider using TWO TABLES in a one to many relationship: Packs and Boards.
The Boards table would have a PackID (as a link to the pack), and fields for
Length, Width, Thickness and Quantity. So if you have a pack containing 15
boards, 5cm thick, 25cm wide, 2m long, you would have a record with those
values; if the pack also contains boards of other sizes, you'ld have
additional records for THOSE boards. You can then easily use a Totals query to
calculate the lineal measurement (what my carpenter friends here in the
benighted US would call "board feed" I presume).
It will be possible (a bit tedious but not too bad) to use a "Normalizing
Union Query" to migrate the existing data from your wide-flat table into the
new table; and you can create a Crosstab query to *present* the data in
spreadsheet form if you wish.
John W. Vinson [MVP]