relationship on tables

[access baby]

I have 5 tables need to create relationship

Customer Table
CustomerID(auto number)(primary key)
Customer Name(text)
Customer City(text)
Customer St(txt)

Customer OrderTable
Customer Number(txt)(primary key)
Company tel. Ph lines- Number
Parted Company Tel. ph Lines -- Number
remote worker branch- txt/ yes no
Number virtual tel.ph NOs. - number
site No. - number
Review board Approval - blank or yes no
Contract signed - date
Project Initation- Date
service type -text
Equipment type - text
Employee Tbl
EmpID(auto no)(primary key)
Emp Fs Name(txt)
Emp Ls Name(txt)

IpSuborder Table
suborder- Number (primary key)
schedule testing- date
conduct v testing- date
checkout -date
acd -date
sch.test turn- date
plns switch- date
transport t- date
conduct company test turn- date
cported -date
maintenance acceptance - date
reason order days- text/ memo
order completed - date
order cancel -date
order disconnect- date

mostly my queries and report will be based on suborder table.

Thanks

Nisha Patel

[Larry Linson]

You will need a "foreign key" in compatible field format the table on the
many side to the main table to which it is related (if it is a one-to-one
relationship, it's arbitrary which is the main and which is the related
table; if it is a many-to-many, you'll need a junction or intersection
table... not as simple). In an order database, the Orders Table is usually
the main/central focus.

Search at http://support.microsoft.com in the Knowledge Base for "Orders and
Solutions" for a sample Orders database to examine.

Larry Linson
Microsoft Access MVP
"access baby" <ni*******@gmail.comwrote in message
news:11**********************@p77g2000hsh.googlegr oups.com...

>I have 5 tables need to create relationship

Customer Table
CustomerID(auto number)(primary key)
Customer Name(text)
Customer City(text)
Customer St(txt)

Customer OrderTable
Customer Number(txt)(primary key)
Company tel. Ph lines- Number
Parted Company Tel. ph Lines -- Number
remote worker branch- txt/ yes no
Number virtual tel.ph NOs. - number
site No. - number
Review board Approval - blank or yes no
Contract signed - date
Project Initation- Date
service type -text
Equipment type - text
Employee Tbl
EmpID(auto no)(primary key)
Emp Fs Name(txt)
Emp Ls Name(txt)

IpSuborder Table
suborder- Number (primary key)
schedule testing- date
conduct v testing- date
checkout -date
acd -date
sch.test turn- date
plns switch- date
transport t- date
conduct company test turn- date
cported -date
maintenance acceptance - date
reason order days- text/ memo
order completed - date
order cancel -date
order disconnect- date

mostly my queries and report will be based on suborder table.

Thanks

Nisha Patel

[Jamie Collins]

On Apr 4, 6:04 pm, "Larry Linson" <[e-mail]:
Your reply here is of such poor quality, IMO, that I'm hoping you are
aaron kempf's alter ego...

You will need a "foreign key" in compatible field format the table on the
many side to the main table to which it is related

Have you given any thought to the meaning of your phrase, "compatible
field format"? Can you explain what relevance field formatting has to
a foreign key? (None, I suspect.)

What do you mean by "main table" and "related table"?

Consider the following SQL DDL (Data Definition Language) snippet:

CREATE TABLE OrderDetails (
order_ID INTEGER NOT NULL
REFERENCES Orders (order_ID)

The correct terms for the two tables in a foreign key definition (i.e.
those found in the SQL literature) are 'referenced table' and
'referencing table' respectively.

I was going to give you the benefit of the doubt and infer that by
"main table" you meant referenced table and by "related table" you
meant referencing table, but then you said,

if it is a one-to-one
relationship, it's arbitrary which is the main and which is the related
table; if it is a many-to-many, you'll need a junction or intersection
table

Junction tables are used to model all relationships between entities
(which I why I prefer the name 'relationship table') i.e. not limited
to many-to-many relationships and include one-to-many and one-to-one
relationships.

Let's rewrite your sentence using the correct terminology: "If it is a
one-to-one relationship, it's arbitrary which is the referenced table
and which is the referencing table." Do you now see the problem?
That's right: the junction table is *always* the referencing table!

Jamie.

--