Bon, the solution here will be to redesign the tables so it works as a
relational database, not like a spreadsheet.
Whatever your main record is (an order perhaps), it seems like it can have
up to 20 entries. In a relational database, you create a related table where
you can have many *records*, instead of many columns in the one table.
You will end up with 2 tables, like this:
Orders table:
- OrderID AutoNumber primary key
- OrderDate Date/Time
- ClientID who ordered this.
OrderDetail table:
- OrderDetailID AutoNumber primary key
- OrderID which order this row belongs to.
- LumberID what kind of lumber was ordered.
- LumberLength Number how long
- Quantity Number how many
There will be other tables too, such as a table of clients (since one client
hopefully has many orders), and a table of lumber (defining the products you
sell. In fact, this might contain other products like fixings as well.)
You will interface this as a main form bound to the Orders table, with a
subform bound to the OrderDetail table. Show the subform in Continuous Form
view, so you can see each order line item on a row of its own, one under the
other.
You can now create a report, with a group header for LumberID and
LumberLength, and sum/count whatever you need.
If this idea is new to you, you might like to get Microsoft's Northwind
sample database and see how it works. Open the Relationships window (Design
tab of ribbon in Access 2007, or Tools menu in earlier versions.) You will
see the tables are set up very similarly to what we suggested for you.
For another example of designing these one-to-many relationships, see:
Relationships between Tables (School Grades example)
at:
http://allenbrowne.com/casu-06.html
For further reading on the art of normalization, here's some more links:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html#DatabaseDesign101