Creating Lookup Fields

John !! I DID IT !! I DID IT !!!! I got the child table to work WOOHOO
!!!!!!!!!!!! It works perfect. Now I just need to apply what I learned here
to the quilt table and hopefully I'll be alright

Thank you sooooooo much !!!!

"John W. Vinson" wrote:

On Sun, 10 Feb 2008 10:52:01 -0800, ASoldiersBride
wrote:

As of right now I have no family table as I've been waiting to figure out the
best way to do it. The information I'll have in the family table is the
first and last name of the parent that's here in the states with all the
normal contact info, servicemember's name, servicemember's unit, then the
child(ren)'s name(s) and age(s)

You need TWO TABLES. You're still thinking that you can put multiple children
into one field, or into one record in the family table. Even with a Multivalue
field you *CAN'T* - a multivalue field is actually a concealed second table!!!

What you need is a table of Families, with FamilyID as its primary key, name
and contact information, etc. The FamilyID might be an Autonumber or, if
available and appropriate, the service member's military ID (since that can be
counted on to be unique and stable).

You would then have a SEPARATE Children table, with ChildID (probably
autonumber) as its primary key, and a FamilyID field (not unique and not the
primary key) as a link to the Families table.

Once I know the proper way to do this table in order for the quilt table to
work then I'll build the quilt table which will house parent's name (lookup
field), child's name (one quilt record per child in the family ~ this is
where I'm askin for y'alls help), quilter (lookup field) then fields for
different dates having to do with the quilt

Again: I'll yell it, since I have to do so to get through the misleading
Microsoft propaganda.

NEVER USE LOOKUP FIELDS.

Never. Ever.

They are confusing, misleading, obnoxious, all but useless... and the Hot New
Thing from Microsoft, so they keep pushing them.

It is *never under any circumstances* necessary to use a lookup field. It is
possible to use a lookup field, and (he grudgingly admits) can even save a few
moments' work in setting up forms - but their small advantages are, in my
opinion, vastly outweighed by the confusion they cause, which is exactly what
you are experiencing!!!!

I would recommend that you NOT store the child's name or other information in
the Quilt table; a quilt is not a child, and a child is not a quilt! Each type
of entity should have its own table. If a Quilt belongs to a Child, you would
have the ChildID as a foreign key (bound to a combo box on a form, but NOT a
Lookup Field in the table!!).

Similarly, if each Quilt has multiple associated Dates, use a Dates table with
a QuiltID (a link to the quilts table, indicating which quilt you're talking
about); an EventType specifying what kind of date this record contains; an
EventDate (don't use the reserved word Date as the fieldname). Each kind of
event for which you're tracking dates would get an additional record in this
Dates table, which would be tied in to the Quilts table by the QuiltID.
--
John W. Vinson [MVP]

On Mon, 11 Feb 2008 16:02:04 -0800, ASoldiersBride
wrote:

John !! I DID IT !! I DID IT !!!! I got the child table to work WOOHOO
!!!!!!!!!!!! It works perfect.


Sounds like she got it. g

Now I just need to apply what I learned here
to the quilt table and hopefully I'll be alright

Once you get the principle you'll see how universal it actually is!
--
John W. Vinson [MVP]