David,
I suggest normalising the tables first, as if you were starting from
scratch.
There will be a way to get your existing data into the revised table
structure, using Append Queries and Update Queries, but we can cross
that bridge when we come to it.
Once again, I am not yet familiar enough with your business processes to
be definitive. But it seems to me that the sample positions data needs
to be normalised as well. Does each box throughout the whole system
have a unique [box number]? If so, I *imagine* you would have a table
like this:
Table: Boxes
- Box Number (PK)
- Rack Number
- Freezer Number
- Box Location
That means in your Samples table, you only need a [Box Number] foreign
key field in order to identify the sample position.
So, in addition to that Boxes table, I *imagine* the following rough
outline:
Table: Patients
- Patient Number (PK)
- PatientName
- Address
- Phone
… other patient-specific information
(I think you mentioned you already have a Patient Number?)
Table: Visits
- VisitID (PK - use an Autonumber?)
- Patient Number (FK)
- DateOfVisit
- ClinicianSeen
… other visit-specific information
Table: Samples
- SampleID (Autonumber PK)
- VisitID (FK)
- Box Number (FK)
- Sample Type
… other sample-specific information
So that way, a patient's record is entered one time. For each time they
visit, the visit data is entered one time. And then, for each of the
visits, the 6 samples are entered, along with the position.
This is really for a later step, but it may be that your data entry
interface turns out to use something like the structure defined in this
article:
http://accesstips.datamanagementsolutions.biz/subsub.htm and
this may then provide you with sufficient power to search the records
you want with nothing further required, in which case your original
question evaporates.
Maybe.
On a related subject, you may also benefit from reading
http://accesstips.datamanagementsolutions.biz/primarykey.htm
(acknowledging that this is one of a number of possible viewpoints!)
So, please let us know whether this is making any sense now.
--
Steve Schapel, Microsoft Access MVP
Ok,
I still have the original table which has 42,000 sample positions defined by
[freezer number], [rack number], [box number], and [box location] which can
be concanentated into one field [sample location ID]. I assume this would
make a useful primary key for this table. Each sample position has all the
relevant information for each table on the same table. This same table has
all the other fields we talked about which details the samples for each
position [date] [visit number] [sample type].
I don't understand how to break this down into seperate tables. At each
visit 6 different types of sample are taken. Some patients have already had
30 visits and this number will continue to rise indefinitely.