Multi-table lookups

[Rob Mazur]

Hi. I'm trying to create a query that pulls information
from 3 seperate tables. Here's how I want it to work:

User is prompted for SSN

Table 1:
SSN
Name
Gender

Table 2:
SSN
Age
Repetitions

Table 3:
Gender
Age
Repetitions
Score

After the user inputs the SSN, I need to look up the score
from table 3 based on age and repetitions from table 2. I
thought DLookUp() was the way to do it, but (1) I've been
having problems with it and (2) I've read that it isn't
the most effective way to lookup that kind of information.

Can anyone help me? I can create this query either
through QBE or SQL.

Thanks

Rob Mazur

[TC]

Rob, no-one can reliably answer questions like this, unless you state the
primary key of each table involved.

HTH,
TC
"Rob Mazur" <rp*****@hotmai l.com> wrote in message
news:2d******** *************** ***@posting.goo gle.com...

Hi. I'm trying to create a query that pulls information
from 3 seperate tables. Here's how I want it to work:

User is prompted for SSN

Table 1:
SSN
Name
Gender

Table 2:
SSN
Age
Repetitions

Table 3:
Gender
Age
Repetitions
Score

After the user inputs the SSN, I need to look up the score
from table 3 based on age and repetitions from table 2. I
thought DLookUp() was the way to do it, but (1) I've been
having problems with it and (2) I've read that it isn't
the most effective way to lookup that kind of information.

Can anyone help me? I can create this query either
through QBE or SQL.

Thanks

Rob Mazur

[Pieter Linden]

Why do you have/need 3 tables? Can't Tables 1 and 2 be merged? How
are they related (1-1, 1-M?) What are you *really* trying to achieve
here? What's in the "repetition s" table? Rules?

Don't know about anyone else, but I'd certainly need more information
before I could even guess what's going on. My initial guess is that
you need to normalize, but I can't even tell that without further
information about what you're trying to model.

[Rob Mazur]

pi********@hotm ail.com (Pieter Linden) wrote in message news:<bf******* *************** ***@posting.goo gle.com>...

Why do you have/need 3 tables? Can't Tables 1 and 2 be merged? How
are they related (1-1, 1-M?) What are you *really* trying to achieve
here? What's in the "repetition s" table? Rules?

Don't know about anyone else, but I'd certainly need more information
before I could even guess what's going on. My initial guess is that
you need to normalize, but I can't even tell that without further
information about what you're trying to model.

Okay, here's the scoop. I have 3 tables: (1) Solider Information
(Name, Gender, SSN[Primary Key], Unit), (2) APFT Record (SSN, Rank,
Age, PTTestDate, PURaw, SURaw, 2MileRunRaw, etc), (3) ScoreLookup
(Age, PURaw, PUScore, SURaw, 2MileRunRaw, 2MileRunScore).

The thought here was to have individual tables for Solider
Information, PT Test scores and the ScoreLookup table would contain
the Raw score (repetitions) to actual score. For example, a 19 year
old Male who did 40 push ups has a score of 57. So, the lookup needs
to be based on age, gender and raw score.

I felt from a management standpoint having this information in
seperate tables would be easier. Honestly, I'm not sure if that's the
right/best way to accomplish this task. Since PT Tests are held at a
minimum of every 6 months, there would be at least 2 entries in the
APFT table (possibly more depending on length of stay at a duty
station). I couldn't use the [APFT Record].[SSN] as a primary key,
because it wouldn't allow duplicate entries (unless my relationship
was screwed up.)

Thanks for your help on this.

Rob

[MGFoster]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd change the table designs (the below CREATE TABLE statements use
the ANSI/JET DDL):

Table Units is a lookup table of Unit names associated w/ ID numbers
that other tables will use instead of the Unit name.

CREATE TABLE Units (
Unit COUNTER NOT NULL , -- Counter is JET AutoNumber
UnitName VARCHAR(35) NOT NULL PRIMARY KEY,
CONSTRAINT idxUnit UNIQUE (Unit)
)

Personal info (Age & Rank) particular to one individual (solider)
usually should be in the same table instead of in many tables
(Soliders & PTTests).

CREATE TABLE Soliders (
SoliderID COUNTER NOT NULL ,
SSN VARCHAR(9) NOT NULL PRIMARY KEY,
LastName VARCHAR(25) NOT NULL,
FirstName VARCHAR(20) ,
Rank VARCHAR(5) NOT NULL ,
Age INTEGER ,
Unit INTEGER NOT NULL REFERENCES Units,
CONSTRAINT idxSoliderID UNIQUE (SoliderID)
)

Table PTTests is another lookup table that will be used like the Units
table. This table helps normalize the APFT and ScoreLookup tables -
you don't have to have a column for each test.

CREATE TABLE PTTests (
TestID COUNTER NOT NULL CONSTRAINT idxTestID UNIQUE ,
TestName VARCHAR(30) NOT NULL PRIMARY KEY
)

PTTests data would look like this:

TestID TestName
- ------ --------
1 PURaw
2 PUScore
3 SURaw
4 2MileRunRaw
.... etc. ...

I'm not sure about the "raw" and "score" test names. These may be 2
different things. IOW, the Tests may in fact be PU, SU, 2MileRun,
etc., and Raw is a datum that is independent of the solider's score -
i.e., the Raw value is a value that the solider's test score is
compared against. Correct? Anyway, I made the remaining tables using
that assumption.

[APFT = Army Physical Fitness Test?]

This table holds each solider's test score, per test date. This is
the table that will have the most "work" (data entry). SoliderID
refers to table Soliders - there is where you'll get the solider's age
& rank. The primary key allows only one type of test per solider per
date.

CREATE TABLE APFT (
SoliderID INTEGER NOT NULL REFERENCES Soliders ,
PTTestDate DATETIME NOT NULL ,
TestID INTEGER NOT NULL REFERENCES PTTests ,
Score INTEGER NOT NULL ,
CONSTRAINT PK_APFT PRIMARY KEY (SoliderID, PTTestDate, TestID)
)

CREATE TABLE ScoreLookup (
TestID INTEGER NOT NULL REFERENCES PTTests ,
Age INTEGER NOT NULL ,
Raw INTEGER NOT NULL PRIMARY KEY ,
CONSTRAINT PK_ScoreLookup PRIMARY KEY (TestID, Age, Raw)
)

I'm not sure about this table - I'm assuming it holds data about what
the aveage/lowest (?) "raw" score is for each age group, per test.
That's the way I set it up.

- --
MGFoster:::mgf
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBP8OVE4echKq OuFEgEQLrHQCeKh okd+HLn6eMr4+jM BhAmjU295QAoNrI
e4CmBe3NIBPQQUg Kx8nmsO0y
=ZNJC
-----END PGP SIGNATURE-----
Rob Mazur wrote:

pi********@hotm ail.com (Pieter Linden) wrote in message news:<bf******* *************** ***@posting.goo gle.com>...

Why do you have/need 3 tables? Can't Tables 1 and 2 be merged? How
are they related (1-1, 1-M?) What are you *really* trying to achieve
here? What's in the "repetition s" table? Rules?

Don't know about anyone else, but I'd certainly need more information
before I could even guess what's going on. My initial guess is that
you need to normalize, but I can't even tell that without further
information about what you're trying to model.

Okay, here's the scoop. I have 3 tables: (1) Solider Information
(Name, Gender, SSN[Primary Key], Unit), (2) APFT Record (SSN, Rank,
Age, PTTestDate, PURaw, SURaw, 2MileRunRaw, etc), (3) ScoreLookup
(Age, PURaw, PUScore, SURaw, 2MileRunRaw, 2MileRunScore).

The thought here was to have individual tables for Solider
Information, PT Test scores and the ScoreLookup table would contain
the Raw score (repetitions) to actual score. For example, a 19 year
old Male who did 40 push ups has a score of 57. So, the lookup needs
to be based on age, gender and raw score.

I felt from a management standpoint having this information in
seperate tables would be easier. Honestly, I'm not sure if that's the
right/best way to accomplish this task. Since PT Tests are held at a
minimum of every 6 months, there would be at least 2 entries in the
APFT table (possibly more depending on length of stay at a duty
station). I couldn't use the [APFT Record].[SSN] as a primary key,
because it wouldn't allow duplicate entries (unless my relationship
was screwed up.)

Thanks for your help on this.

Rob

[TC]

"Rob Mazur" <rp*****@hotmai l.com> wrote in message
news:2d******** *************** ***@posting.goo gle.com...

pi********@hotm ail.com (Pieter Linden) wrote in message

news:<bf******* *************** ***@posting.goo gle.com>...

Why do you have/need 3 tables? Can't Tables 1 and 2 be merged? How
are they related (1-1, 1-M?) What are you *really* trying to achieve
here? What's in the "repetition s" table? Rules?

Don't know about anyone else, but I'd certainly need more information
before I could even guess what's going on. My initial guess is that
you need to normalize, but I can't even tell that without further
information about what you're trying to model.

Okay, here's the scoop. I have 3 tables: (1) Solider Information
(Name, Gender, SSN[Primary Key], Unit), (2) APFT Record (SSN, Rank,
Age, PTTestDate, PURaw, SURaw, 2MileRunRaw, etc), (3) ScoreLookup
(Age, PURaw, PUScore, SURaw, 2MileRunRaw, 2MileRunScore).

(snip)

You're still not giving the primary key for each table. Believe me, this
will cause you grief in the long run.

TC

[Rob Mazur]

"TC" <a@b.c.d> wrote in message news:<106981578 6.72334@teuthos >...

"Rob Mazur" <rp*****@hotmai l.com> wrote in message
news:2d******** *************** ***@posting.goo gle.com...

pi********@hotm ail.com (Pieter Linden) wrote in message

news:<bf******* *************** ***@posting.goo gle.com>...

Why do you have/need 3 tables? Can't Tables 1 and 2 be merged? How
are they related (1-1, 1-M?) What are you *really* trying to achieve
here? What's in the "repetition s" table? Rules?

Don't know about anyone else, but I'd certainly need more information
before I could even guess what's going on. My initial guess is that
you need to normalize, but I can't even tell that without further
information about what you're trying to model.

Okay, here's the scoop. I have 3 tables: (1) Solider Information
(Name, Gender, SSN[Primary Key], Unit), (2) APFT Record (SSN, Rank,
Age, PTTestDate, PURaw, SURaw, 2MileRunRaw, etc), (3) ScoreLookup
(Age, PURaw, PUScore, SURaw, 2MileRunRaw, 2MileRunScore).

(snip)

You're still not giving the primary key for each table. Believe me, this
will cause you grief in the long run.

TC

TC:

That's part of the problem. I've tried a couple of different primary
keys with no success. Any suggestions on that?

Also, it was suggested the the Solider Information and APFT Record
tables be combined. Good/Bad idea?

Thanks for the help so far.

Rob

[cafe]

"Rob Mazur" <rp*****@hotmai l.com> wrote in message
news:2d******** *************** ***@posting.goo gle.com...

"TC" <a@b.c.d> wrote in message news:<106981578 6.72334@teuthos >...

"Rob Mazur" <rp*****@hotmai l.com> wrote in message
news:2d******** *************** ***@posting.goo gle.com...

pi********@hotm ail.com (Pieter Linden) wrote in message

news:<bf******* *************** ***@posting.goo gle.com>...

> Why do you have/need 3 tables? Can't Tables 1 and 2 be merged? How
> are they related (1-1, 1-M?) What are you *really* trying to achieve > here? What's in the "repetition s" table? Rules?
>
> Don't know about anyone else, but I'd certainly need more information > before I could even guess what's going on. My initial guess is that
> you need to normalize, but I can't even tell that without further
> information about what you're trying to model.

Okay, here's the scoop. I have 3 tables: (1) Solider Information
(Name, Gender, SSN[Primary Key], Unit), (2) APFT Record (SSN, Rank,
Age, PTTestDate, PURaw, SURaw, 2MileRunRaw, etc), (3) ScoreLookup
(Age, PURaw, PUScore, SURaw, 2MileRunRaw, 2MileRunScore).

(snip)

You're still not giving the primary key for each table. Believe me, this
will cause you grief in the long run.

TC

TC:

That's part of the problem. I've tried a couple of different primary
keys with no success. Any suggestions on that?

Also, it was suggested the the Solider Information and APFT Record
tables be combined. Good/Bad idea?

Thanks for the help so far.

Rob

Rob, post the fields of the specific table in question, & a brief
description of what a single row in that table, represents. Something along
the following lines:

tblPerson - one row for each person known to the system.
surname - person's surname
DOB - person's date of birth.
etc.

Then we can help you find the primary key.

Primary keys are a fundamentl component of a relational database management
system like Access. Nothing else will work properly - everything else will
go wrong - if you don't have the right primary keys.

HTH,
TC

[Rob Mazur]

">

Rob, post the fields of the specific table in question, & a brief
description of what a single row in that table, represents. Something along
the following lines:

tblPerson - one row for each person known to the system.
surname - person's surname
DOB - person's date of birth.
etc.

Then we can help you find the primary key.

Primary keys are a fundamentl component of a relational database management
system like Access. Nothing else will work properly - everything else will
go wrong - if you don't have the right primary keys.

HTH,
TC

TC:

I apologize for not posting a reply sooner, it's been busy around
here. I willpost those tables/fields tomorrow AM.

Thanks again