>Read more details about foreign key constraint with one example at
>
>http://www.dbforums.com/archive/index.php/t-1011472.html

He-he. Now I see what you've been quoted Tim Witort (don't know him, though):

Tim WitortGene Wirchenko seemed to utter in news:ne3pe0pspjmt9gofnimbr0ngh44413gqms@
4ax.com:

> Permit me to quote from a textbook: "A foreign key must satisfy
> referential integrity, which specifies that the value of an attribute
> in one relation depends on the value of the same attribute in another
> relation." [1] I could find a number of others from the program that
> I just graduated from.

That is not a very clear definition of a foreign key, of course
who knows what context that sentence was in. Anyway, a foreign
key does not, in and of itself, *enforce* referential integrity.
Who knows what this author meant by "satisfying" RI? That is
just a bad, vague choice of words. But again, maybe they weren't
trying to define a foreign key in the passage you quoted.

A foreign key is a logical database element. Depending on
*how the foreign key is declared* determines how it functions
in the database. This is true in all RDBMSs that I've worked
with from Oracle to Sybase to VFP. Since you just graduated
from a program, I'm sure are familiar with database design and
the difference between "logical" and "physical" database design
elements. Now, in VFP, establishing RI is not done in the
CREATE TABLE statement; it happens to be done using the RI
builder. Other databases *do* allow RI to be setup in the
DDL alongside the foreign key definition. But I don't recall
ever seeing an RDBMS which *required* you to establish an
RI rule or restriction when declaring a foreign key.

> If an FK is not required to inherently satisfy RI, then 1) what
> is the point of a foreign key constraint and 2) how is a foreign key
> constraint a constraint since it is not constraining anything?

You are mixing two terms here. A foreign key is not the same
thing as a foreign key constraint. You can have a foreign key
without a FK constraint. But not vice versa.

> The idea that foreign keys are not enforced automatically by the
> DBMS is ludicrous. If this really is how foreign keys work in VFP, we
> have been ripped off. It does explain why I have been having trouble
> with it though.

VFP does do this. You just declare the constraint in the RI
builder - not in the DDL. From then on, the DBMS takes care
of enforcing it. Nobody has been ripped off. You just need
to learn how VFP implements this.

> Why would anyone bother declaring a foreign key constraint if it
> does not do anything anyway?

Again, you are mixing two concepts and terms here. You declare
a FK constraint in VFP in the RI builder and believe me, these
do work. You seem to be implying that, if you have a child table
related by a foreign key to a parent table, then there *must* be
some restriction on how data is inserted, changed, or deleted
in these tables. Well, there isn't. After you've designed and
implemented a few dozen real world databases, you might discover
that things don't fall nicely into your textbook definitions.
This is why RDBMSs provide the flexibility to define foreign
keys with and without constraint rules. Sometimes you *do* want
the deletion of the parent record to leave orphaned child
records. Sometimes you *do* want to insert child records
that are not related to an existing parent record.