Let's suppose I add an arbitrary number to each record. I still can't tell
them apart without some other sort of information. What that may be depends
on the circumstances. If I am storing course information I will probably
use StudentID. Since StudentID is what distinguishes them from each other,
I will just use that as the PK. If two people with the same name enter the
school the same year, are in the same graduating class, and have the same
middle initial, I will need to come up with something else to assure they
are not confused with each other in the records. I am not going to use a
multi-field PK. Names and addresses change. A name and address combination
is a poor choice for PK. Updating many records if somebody's address
changes makes no sense whatever. It destroys the whole point of using a
relational database.

"Amy Blankenship" wrote in message
...
And what if you absolutely have to tell Miss NE personID = 1 from Miss NE
personID = 2, for exam results and such? For a contact database it may
NOT be important who it is, but for other purposes, like storing course
completion results, etc., it is VERY important!

-Amy

"BruceM" wrote in message
...
"I do not rely on front end applications to enforce data integrity and
would strongly discourage such development. If I have a business rule
which Jet cannot enforce via constraints then I would recommend porting
to MSDE."

I really don't know what you mean by "porting to MSDE". I found out what
MSDE is, but for my purposes I will find a way to validate the data,
whether at the table level or in the front end. You can strongly
discourage using the front end for such purposes, but have not provided a
reason why. If there is a Spouse First Name field it may be required if
the person is married, but certainly not otherwise. My choice is the
front end for such validation rather than another piece of software.
Before Update works for my purposes. I will continue to use it. Data
integrity is not compromised. The database works smoothly and quickly.
If it is "inefficient" it is so on a level that is not important to me.

"Miss N E Person ID=1 of Main Street and Miss N E Person ID=2 of Main
Street are different people". Then I will figure out a way of telling
them apart that is useful to the person who needs to call or contact one
or the other. Knowing that they are different records in the database
(because they have different ID numbers) is not helpful in telling them
apart.

wrote in message
oups.com...

BruceM wrote:
I think I understand that your PK and your field(s) on the one side of
one-to-many may not be the same. If so, and if the PK is not part of a
relationship, would the purpose of your PK be to guard against
duplication?

No, it would be the 'field(s) on the one side of one-to-many' that
would guard against duplication. The purpose of the PK would be to
avoid a performance-degrading clustered index and, if possible, to
provide for a performance-enhancing clustered index.

If so, do you regard that as a more efficient use of recources than
data
validation code in the form's Before Update event?

I do not rely on front end applications to enforce data integrity and
would strongly discourage such development. If I have a business rule
which Jet cannot enforce via constraints then I would recommend porting
to MSDE. For me, 'efficiency' doesn't come anything close to data
integrity in terms of importance.

Also, if by "expose it" (in reference to an artificial key) you mean
show it
to the user, why would that be necessary?

You know Miss N E Person ID=1 of Main Street and Miss N E Person ID=2
of Main Street are different people, but when you speak to one of them
on the phone, how do *they* tell you which one they are?