By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,455 Members | 1,979 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,455 IT Pros & Developers. It's quick & easy.

Table relationship problem

P: n/a
I think I am having problems with table relationships. Here is what I
have.

Table 1 has Social Security Number
First Name
Last Name
Autonumber
Since I will have many duplicate Social Security Numbers, Autonumber
is the primary key.

Table 2 has Social Security No
Notes

I joined the two tables with an indeterminant relationship using Social
Security Number and Social Security No. I want to use Social Security
No (Table 2) to pull the corresponding name from Table 1.

I built this query:
Social Security No - Table 2
First Name - Table 1
Last Name - Table 1
Notes - Table 2

The query works just as I need it, but whenever I build a form based on
the query, the form will not work. It opens with the error the the
Recordset is not undateable. What does this mean and how do I make
this work?

May 2 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
you can't create a relationship that will allow you to add records in a
form if the type is indeterminate. Think about it - how does the
database engine enforce referential integrity if there's no way to tell
which table is the parent and which is the child?

How do you make it work? Join on the Autonumber PK. Just add a Long
Integer type field to the child table.

May 2 '06 #2

P: n/a
pi********@hotmail.com wrote in
news:11*********************@v46g2000cwv.googlegro ups.com:
you can't create a relationship that will allow you to add
records in a form if the type is indeterminate. Think about
it - how does the database engine enforce referential
integrity if there's no way to tell which table is the parent
and which is the child?

How do you make it work? Join on the Autonumber PK. Just add
a Long Integer type field to the child table.

No, no, no. The pk of the first table should be the SSN, as that is
assigned to an individual. If there are duplicates, they are
sources of error, because they must refer to one individual, or you
are missing the Country which issued the SSN..

--
Bob Quintal

PA is y I've altered my email address.
May 2 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.