Help creating form

[Guest]

Hi
I have a dbase with the following four tables.... "Company Info" (fields: Name(PK); Main address; phone; relationsip status
"Contact Info" (fields: company; contact name (PK); address; phone; fax; e-mail) "Project Info" (fields: company; project (PK); location; lead origin; lead status) and "Contact Log" (fields: project(PK); type; date; notes; action; action date (there are four lots of each field in this table to allow entry of four different contacts)).

My relationships are "from Company Info - Name" "to Contact Info - Company" "from Contact Info - Company" "to Project Info - Company" "from Project Info - Project" "to Contact Log - Project

Is all the above okay? If so, what's the best way to create a form for it, probably put Contact log as subform????

 

[Larry Linson]

Hi,
I have a dbase with the following four tables.... "Company Info" (fields:

Name(PK); Main address; phone; relationsip status)

"Contact Info" (fields: company; contact name (PK); address; phone; fax;

e-mail) "Project Info" (fields: company; project (PK); location; lead
origin; lead status) and "Contact Log" (fields: project(PK); type; date;
notes; action; action date (there are four lots of each field in this table
to allow entry of four different contacts)).

My relationships are "from Company Info - Name" "to Contact Info -

Company" "from Contact Info - Company" "to Project Info - Company" "from
Project Info - Project" "to Contact Log - Project"

Is all the above okay? If so, what's the best way to create a form for

it, probably put Contact log as subform????

Your description of the Contact Log table definitely seems "unnormalized",
that is, it has repeating information. You should consider having a separate
record for each Contact Log entry, in a many-to-one relationship with the
Project table. Each Contact Log record would have its own unique identifier
(probably a PK) with a foreign key to identify the Project to which it
applies. That way, there can be no contact logs, or as many as are needed.

Given that we don't really know how you intend to use the data, it's
difficult to assess the overall design. Your database should "model the real
world", although it can be simplified from "the real world"*, and that will
depend on how you need to access the information and how you use it.

* Einstein is reputed to have said things should be "as
simple as possible, but no simpler." <G>

Larry Linson
Microsoft Access MVP