microsoft office help is only confusing me!

[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

 

[Jeff Boyce]

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

 

[melinda.pluma]

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 -

hilarious! 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.

 

[Jeff Boyce]

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

 

[John W. Vinson]

hilarious! 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.

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]

 

[Spurious Response]

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.

 

[Jeff Boyce]

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

 

[Spurious Response]

Read it again. I did not refer to a table as being a key.

 

[John W. Vinson]

Read it again. I did not refer to a table as being a key.

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]

 

[Spurious Response]

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

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".

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.

 

[Spurious Response]

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

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.

 

[Keith Wilby]

Have a wonderful day in a one way world.

Peter Gabriel?

 

[Spurious Response]

Peter Gabriel?

Of course.