jesusoneez
IT Dogsbody
- Local time
- Today, 08:56
- Joined
- Jan 22, 2001
- Messages
- 109
It's my understanding of general database practice that an Autonumber field should be used as a primary key in normalisation tables. I realise my understanding could be wrong, and I'm quite happy to change that practice if need be.
I have my normalisation tables. For the most part these consist of an Autonumber field ([UID]) as the primary key, then an indexed, no duplicates text field with the normalisation data. For this case, we'll say it's a list of departments ([DepartmentID]).
I have a form for entering users. Again, the PK is an autonumber field. I used a wizard to create a combo box. I selected the fact that I want to store the value in [DepartmentID], NOT [UID].
This works fine, I can add my users and the combo boxes work, although I had to change the bound column to 2, as 1 is selected by default although it is [UID].
I then created a subform based on a query of all users. This subform is not bound to the main form in any way, it simply shows the result of the query.
When entering users, upon saving a record, the form is updated and the new user shown in the subform. Great, apart from "txtDepartment" in the subform showing [UID], and not [DepartmentID] as stipulated.
I have a horrible feeling this is to do with [UID] being my PK, but I'd like someone to tell me I'm wrong. I can quite happily remove the autonumber field [UID] and make the unique [DepartmentID] field the PK, but this just doesn't seem "correct" to me.
Should I do this? Should I have an autonumber field as the PK?
I realise this is more a design theory question than a form problem as such, but anything that clarifies my understanding of correct design practice will help.
EDIT:- I'd also like to say that I did it this way to get away from using the "LOOKUP" field type at table design time, specifically to avoid this very problem of numbers showing up when I want the text there!
I have my normalisation tables. For the most part these consist of an Autonumber field ([UID]) as the primary key, then an indexed, no duplicates text field with the normalisation data. For this case, we'll say it's a list of departments ([DepartmentID]).
I have a form for entering users. Again, the PK is an autonumber field. I used a wizard to create a combo box. I selected the fact that I want to store the value in [DepartmentID], NOT [UID].
This works fine, I can add my users and the combo boxes work, although I had to change the bound column to 2, as 1 is selected by default although it is [UID].
I then created a subform based on a query of all users. This subform is not bound to the main form in any way, it simply shows the result of the query.
When entering users, upon saving a record, the form is updated and the new user shown in the subform. Great, apart from "txtDepartment" in the subform showing [UID], and not [DepartmentID] as stipulated.
I have a horrible feeling this is to do with [UID] being my PK, but I'd like someone to tell me I'm wrong. I can quite happily remove the autonumber field [UID] and make the unique [DepartmentID] field the PK, but this just doesn't seem "correct" to me.
Should I do this? Should I have an autonumber field as the PK?
I realise this is more a design theory question than a form problem as such, but anything that clarifies my understanding of correct design practice will help.
EDIT:- I'd also like to say that I did it this way to get away from using the "LOOKUP" field type at table design time, specifically to avoid this very problem of numbers showing up when I want the text there!
Last edited: