>>>
>>>Yes,
>>>Maybe I didn't express myself clear.
>>>Yes the Referential integrity must be done via the PARENT table primary key and Foreign Key in the Child Table(s).
>>>BUT every table (no matter parent or child it is) SHOULD have Primary key.
>>>
>>>A very rough example why:
>>>

>>>Parent Table 
>>>--------------------------
>>>Id           Name
>>>--------------------------
>>>1            Example 1
>>>2            Example 2
>>>
>>>
>>>
>>>Child Table 
>>>--------------------------
>>>ParentId     SomeOtherField
>>>--------------------------
>>>1            Example 1
>>>1            Example 1
>>>1            Example 1
>>>
>>>2            Example 2
>>>

>>>
>>>As you see you have 3 records in the child table for the ParentID = 1.
>>>And HOW you will UPDATE/DELETE only the FIRST of these records if you didn't have PK for that TABLE?
>>
>>I guess the confusion comes from what I am using as Primary Key. What I was referring to as Candidate key should be called the Primary key. Then what would I call my identity field? Just identity field?; I don't know. Or maybe I ought to redesign my database and use my identity field as primary key and have the same field (like identity in parent table) in the child table(s). Something to think about.
>>
>>Thank you very much for your help.
>
>
>No,
>Candidate key is a Field in the Child table that hold a PK value of the Parent table.
>So RI should be build based on PK of the Parent Table and FK in Child Table.
>
>Candidate Key could NOT be an Identity field, just because you can't synchronize tables that well (even when the Child table should have only one record matching parent table) , do not need to mention that the Child table can have more than one record matching Parent table.

I am confused now <g>. Up above you said that "the Referential integrity must be done via the PARENT table primary key and Foreign Key in the Child Table(s)". I agree with this statement and understand it.

Then, in your last message you said "Candidate key is a Field in the Child table that hold a PK value of the Parent table". Unless I have been misunderstanding the term "candidate" field for a long time, I disagree with this. I would change the term "Candidate" in your sentence with "Foreign." My understanding of a Candidate key (and maybe I was wrong for a long time) is that it is any unique entry field in a table. And this unique field in the table can be "made" into a Primary key.

So in my database design a Primary key field is a field where user makes an entry (e.g. CustomerID). The child tables also have field CustomerID. And the Referential Integrity is built on this Primary key field (CustomerID in Parent to CustomerID in Child). Then, in the Child table there is a Primary (surrogate) key, identity field. And what adds to the confusing is that the Parent table (in my database) also has an identify field. And what I was saying is that the identify field in the Parent table may not be necessary; or, at least, I see no use for it right now.

(The point of my discussing this with you, Borislav, is not to argue, but rather so that I finally have all these terms firmly understood in my head).