microsoft office help is only confusing me!

  • Thread starter Thread starter melinda.pluma
  • Start date Start date
M

melinda.pluma

Can I have a foreign key if I'm working with a Microsoft Access
Database(.mdb), or is a foreign key only available for a Microsoft
Access Project (.adp)?

Thanks
Mindy
 
Mindy

A "foreign key" is a field in a (second) table that contains a value
matching (a primary key value) in a (first) table.

(notice that there's no mention of .adps, .mdbs, or mouse's)

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
Mindy

A "foreign key" is a field in a (second) table that contains a value
matching (a primary key value) in a (first) table.

(notice that there's no mention of .adps, .mdbs, or mouse's)

Regards

Jeff Boyce
Microsoft Office/Access MVP







- Show quoted text -
Click to expand...

hilarious! :P I was trying look up how to create my foreign key and
that's where I'm having problems. Should each database only have one
primary key? I thought for some reason... each table should have a
primary key.
 
Back to my explanation ... keys are related to tables, not databases. A
primary key on a table serves to uniquely identify each row.

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
hilarious! :P I was trying look up how to create my foreign key and
that's where I'm having problems. Should each database only have one
primary key? I thought for some reason... each table should have a
primary key.
Click to expand...

Just don't confuse the terms Table and Database. In some software (dBase for
example) the term "database" is used for what Access calls a Table: one set of
data representing a particular type of entity.

An Access Database (.mdb, .mde, .adp, .etc etc.) is a container for multiple
tables, forms, reports and other objects.

Therefore a Database doesn't have a primary key; however each Table in the
database should have its own primary key.

John W. Vinson [MVP]
 
Yes, so a table that has more than one entry tied to a key in another
table would not / could not be a primary key as primary keyed tables
require only a single entry for each key, or row, just as you stated.
 
Uhm... tables aren't primary keys. A row in ANY table can (and probably
should) be uniquely identified, so any table can have a primary key field
for its rows.

If a row in table2 is related to (e.g., a "child of") a row in table1, then
it (the row in table2) would need a foreign key field to hold the value of
its "parent's" primary key.

Regards

Jeff Boyce
Microsoft Office/Access MVP
 
Read it again. I did not refer to a table as being a key.
Click to expand...

Well, perhaps you didn't intend to; but the sentence reads

Yes, so a table that has <some attribute> would not / could not be a primary
key

The subject of the sentence is "a table"; the predicate is "could not be a
primary key".

John W. Vinson [MVP]
 
Well, perhaps you didn't intend to; but the sentence reads

Yes, so a table that has <some attribute> would not / could not be a primary
key
Click to expand...

MORE THAN ONE ENTRY TIED TO A KEY IN ANOTHER TABLE! NOT "some
attribute".
The subject of the sentence is "a table"; the predicate is "could not be a
primary key".
Click to expand...

The subject of the sentence is an ENTRY in a table, tied to a key in
another table!

Learn to read.

Nice snip, Vinson. Now read the ENTIRE sentence.

"Yes, so a table that has more than one entry tied to a key in another
table would not / could not be a primary key as primary keyed tables
require only a single entry for each key, or row, just as you stated."

The TABLE is TIED to the PRIMARY key in another table. I never
stated that the table itself was a key.

And we ALL know that a "primary keyed table" refers to a specific field
in said table that has been designated as a primary key.

Jeez.
 
An Access Database (.mdb, .mde, .adp, .etc etc.) is a container for multiple
tables, forms, reports and other objects.
Click to expand...

A serious vulnerability from a data integrity POV. One bad bit, and
the whole "database" is gone.

I would prefer to have separate "table", "form", "report" and "query"
files and have a directory of tables and other such items be referred to
as a "database". Being in all one file makes for SLOWER searches, as
well as bloat, and several failure mode vulnerabilities.

The idiot at MS that thought up that one should be fired, and they
should return to the paradigms that have been used for decades now.

This is one of my only problems with the Access "database" paradigm.

MS could learn a LOT from even a "dead" database product such as
Borland's Paradox.

Have a wonderful day in a one way world.
 
Back
Top