Thanks John.
We design and manufacture timber components for our business. This almost
always requires us to supply a bunch of hardware components that we custom
order from a handful of different suppliers. Nuts, bolts, washers, split
rings, rods and custom steel components. This information needs to be
entered into some sort of list by the designer. The designer needs to be
able to do this geographicaly throught the project in order to maintain
accuracy. They dont want to look for all the 3/4" nuts throught the whole
project, then come back and look for all the split rings. The designers are
currently doing this with a excel spreadsheet but it's cumbersome and time
consuming. It seems like a natural fit for a form that can later create
purchase orders to the different suppliers.
Problem is that split rings have different fields asoociated with them,
namely size and finish. Bolts have diameter, length, head shape, grade, and
finish. It would also be convienient to have an option for "add (1) washer
and (1) nut" or "add (2) washers and (1) nut. This information is *always*
compiled into the description field and is never modified. (except for the
exta washer or nut options, those need to be separate records.) Right now,
the designers just type it all into a single excel cell. I'm trying to make
it a little easier for them.
I understand the concept of atomic data in fields, but practiacly, for us,
the compiled description *is* atomic. We never need to sort or query by
"head shape" or grade, but we do need to query by the aggregate info in the
Description field. Right now, if a designer types "3/4"x10" A307 MB Hex Gal"
(3/4" x 10" a307grade, Machine Bolt, Hex head, Galvanized) in one record then
types "3/4"x10" MB A307 MB hex Gal" in another record, the text string forces
them to be "not alike" for query purposes. If I have a VBA routine run when
they hit the "post to table" button, it can concatenate their selections
consistently and accurately.
I know I can have related tables for bolts, split rings, rods,etc., but it
just seems like so much database overhead for such a simple list that it
doesn't seem worth it.
Thanks again.