Dib said:
Thanks for your reply,
What I am trying to do is create tables and a form or Forms for
chemicals testings, one set of testing has 8 different substance
which is 8 Rows. Every time a test has been done I need to be able to
enter a date on that row, if more than one test is made I need to be
enter the dates for all.
I have not done anything yet I am looking for helpful advices from
any one who has done something similar. I have to do this for 5
different set of chemicals, each set contains 8 rows.
This data need to be kept and available for 10 years. and if the user
select to view all the testing dates that has been done, I need to be
able to show all by set (meaning 8 Rows at a time will all date
fields.) I have a copy of the Flow Sheet design. but as requested the
user need unlimited date fields for each Row
any advice will be very help full, on how and where to start.
Okay, here goes. It seems to me you've described three levels of data:
(1) test sets, (2) substances tested -- 8 per set -- and (3) test
dates -- multiple per substance per test set. I don't know whether that
bottom level will have other results recorded besides the dates
themselves; that's certainly a possibility. Based on this structure, I
can see the following table structure:
Table TestSets
---------------
Field TestSetID : primary key
(other fields to describe the test set)
Table TestSubstances
----------------------
Field SubstanceID : primary key
Field SubstanceName : text
(possibly other fields to describe the substance)
(this table has, initially, 8 records)
Table TestsPerformed
-----------------------
Field TestSetID : (foreign key to TestSets)
Field SubstanceID : (foreign key to TestSubstances)
Field TestDate : date
(I'd suggest a compound primary key composed
of all three of the above fields)
(possibly other fields recording test results)
These tables would have a 1 to many to 1 relationship:
TestSets:1<-->M:TestsPerformed:M <--> 1:TestSubstances
The *simplest* and most flexible, test-set oriented way to represent
these relationships is with a main form in single-form view based on
TestSets, and a subform in continuous-forms view based on
TestsPerformed, using a combo box to select and display the
TestSubstance on each subform record. But that may not be the most
effective user interface for people who want to clearly see the test
results clearly segregated by substance. You can build a clearer, but
less flexible form by using 8 separate subforms, one for each substance.
These could be arranged vertically on the main form (as "rows"),
horizontally (as "columns"), or on separate pages of a tab control. The
subforms would be set up with their Link Master Fields set as invisible,
calculated text boxes on the main form with controlsources like
=1
=2
=3
etc. up to 8, where the values 1 through 8 are the SubstanceIDs from
table TestSubstances.
You should be aware that all of these multiple-subform designs, are less
flexible than the single-subform approach, because you're building a
fixed number of test substances into the user interface. However, if
these are really not subject to change very much, and if you'll be
available to make design changes if another substance should be added to
the list, the increased clarity of the UI design is probably worth it.