One to Many

A

ak

I am confused with primary key and foreign key.
Once I connect with primary key and foreign key what are the rules to get
result as want.
Why I ask you this is : I made table_1
with field names : SNO, NAME, WORK_LOCATION, COMPANY
table_2
TRC_NO, DOCUMENT NAME, PROCESS, RCVD FROM, FORWARDED TO, NOTES, SNO
I connected SNO to SNO
Then I get result Table1 as many and Table2 as one. How come this? I fee
logically Table1 should be in one side and Table2 should be in many side.
Please comment. I dont know much about integer, long integer, single, double
etc. Pls explain this too.
 
A

Allen Browne

If SNO is the primary key of Table1, it will be on the ONE side of the
relationship.

When you create the relation, be sure to check the box for:
Referential Integrity

That will help ensure everything is right.
 
S

Stefan Hoffmann

hi,
I am confused with primary key and foreign key.
Once I connect with primary key and foreign key what are the rules to get
result as want.
Why I ask you this is : I made table_1
with field names : SNO, NAME, WORK_LOCATION, COMPANY
table_2
TRC_NO, DOCUMENT NAME, PROCESS, RCVD FROM, FORWARDED TO, NOTES, SNO
I connected SNO to SNO
Then I get result Table1 as many and Table2 as one. How come this? I fee
logically Table1 should be in one side and Table2 should be in many side.
The cardinality of a relationship depends on the indices on the involved
fields.

table_1:
SNO, NAME, WORK_LOCATION, COMPANY

table_2:
TRC_NO, DOCUMENT NAME, PROCESS, RCVD FROM, FORWARDED TO, NOTES, SNO

Connecting the table_1.SNO with table_2.SNO declares a relationship.
According to the primary keys you may have:

- table_1.SNO is the primary key and table_2.SNO is NOT the primary key,
then you have table_1 --1:n--> table2.

- table_1.SNO is the primary key and table_2.SNO is the primary key,
then you have table_1 --1:1--> table2.

- table_1.SNO is NOT the primary key and table_2.SNO is NOT the primary
key, then you have table_1 --m:n--> table2.

So check your primary keys.


mfG
--> stefan <--
 
A

ak

I am not satisfied with your response. Also not clear answer for me.
I believe my question was very clear. I want to know data type in both
tables'
primary key and foreign key should be matched? What are those matching?
What is single, double, integer, long integer? Would appreciate your great
favor.
 
A

Allen Browne

Stefan's reply answered your question precisely.

If you are having trouble with the relationship working the wrong direction,
you have not set up your key fields correctly. So has he says, 'check your
primary keys.'

In general, a foreign key field should be the same data type and size as the
primary key it relates to. So if the primary key is Text (24 characters),
then you should design the foreign key field to be Text (24 characters.) If
the primary key is Integer, then the foreign key should also be Integer. If
the primary key is AutoNumber, the matching foreign key field should be Long
Integer (unless you specifically changed it to a GUID.)

If your primary key is a Single or Double, you may have problems matching it
properly at all:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
 
L

Larry Linson

ak said:
... I want to know data type in both tables'
primary key and foreign key should be matched?

You can create a relationship or a join in a Query between some different
data types (for example, a Long Integer* and an Integer). But to specify
referential integrity, the data types must be the same (for example, a Long
Integer must be paired with a Long Integer).

The Query Builder will let you join a Long Integer to a Text Field, and will
let you save that Query, but when you attempt to execute it, you will get a
"Data type mismatch" error.

* Note that an AutoNumber is the same data type as Long Integer, but
automatically populated.
What are those matching?

I don't understand what you are asking. If you clarify, someone will try to
explain.
What is single, double, integer, long integer?

A newsgroup is an inappropriate place to expect, or to offer, a basic
tutorial on data types. Also, every version of Access has included a Help
file, and though the Help files have been of varying quality, they have all,
every one, had a definition of "data types". However, if you need that
explained, chances are that you need some very basic training. Here are some
suggestions:

In today's homepage* at http://office.microsoft.com/ along the bottom,
you'll see links by subject. Click on the one entitled "Office training
courses", under the heading "Training". That will take you to a page
entitled "Training" and aproximately in the middle of the page, you'll see
two headings "Browse 2007 Office Courses" and "Browse 2003 Office
Courses" -- pick the appropriate one (use 2003 for any version previous to
2007), and click the entry for Access 2007 or Access 2003. I chose Access
2003, which leads to a list of 18 Access 2003 courses at the beginning and
intermediate levels -- I've heard very good feedback from people at those
levels who used them. (I wouldn't be a good judge as I passed those levels
in Access' early days.)

The Access 2007 product has a much-changed user interface, and while most of
the underlying information in the Access 2003 courses will still apply, the
"how-to-use" instructions will be useless with Access 2007. So for Access
2007, on the Training Page, choose Access 2007. There are only 9 courses
available, so far, for Access 2007, but they'll give you a good start.

Self-study texts are another source:

Microsoft Access xxxx Step by Step, from Microsoft Press, is a good start
for the raw novice or casual end-user.

Using Microsoft Access xxxx - Special Edition, by Roger Jennings, published
by Que, starts from the beginning and goes deeper than some "beginner books"

Access 2003 Inside Out, by John Viescas, and Access 2007 Inside Out, by John
Viescas and Jeff Conrad, from Microsoft Press, are good books with thorough
coverage, and also go deeper than most.

Microsoft Access xxxx Developer's Handbook, by Litwin, Getz, et al,
published by Sybex, is "The Book" that Access Developers covet.
Unfortunately, no new edition has been published since the 2002 edition;
fortunately, the information in the 2002 edition (in two volumes) applies
almost entirely to 2003 as well, and much of it to previous versions.

* in all the above "xxxx" represents the version of Microsoft
Access and/or the edition of the book

There's a list of useful resources (websites, many with examples) on my user
group's page at http://sp.ntpcug.org/accesssig/default.aspx.

These will give you enough reading for quite a while and if you really learn
everything in these, you'll have a very good understanding.

Larry Linson
Microsoft Office Access MVP
 
E

Evi

Ak, you are clearly struggling bravely to learn a very difficult subject
(Access Database Design) using a language you are not completely familiar
with. I do admire your persistence but please remember that no-one here is
being paid to answer your questions. We are not working for Microsoft.

To explain the Primary and Foreign Key thing, I will use a simpler example.

You want your database to list the things you buy and the date you buy them.

The 'One' table, TableItems contains all the things you could ever want to
buy, Each item, tomatoes, potatoes, bread, will only be mentioned once,
that's why its called the One table.
It has 2 fields
ItemID is the Primary Key field - it's an Autonumber
Item - this is thelist of items like bread and tomatos

The Many Table is your TableShoppingList
It has
ListID This is the Primary key field and is an Autonumber
ListDate - the date you did your shopping
ItemID - This is the Foreign Key. If ItemID in TableItems is an Autonumber
then, in this table, ItemID must be a Number field (under DataType, in the
Table Design View) and its Field Size (in the same view must be Long
Integer.

You will use the Relationship window to create a link between ItemID in
TableItems to this ItemID. It is the Foreign key in this table because it is
the Primary Key in TableItems

TableShoppingList is the Many table because you could buy tomatos, bread and
pototaos on many days so their ItemID will appear many times in this table.

Integers are whole numbers (no decimal points).
Long Integers are also whole numbers but can go up to a higher number than
the Integers (can't remember the actual numbers - I THINK Integers can go up
to 32000 but no higher)

single - numbers with a decimal point
Double - bigger numbers with a decimal point.

Evi
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top