L
Larry
Ok, I have a problem I have never had in 13 years of working with MS Access.
I have a Personnel table, with 4 child tables (location information,
compliance information, visa information, validation information for each
person) which are all 1 to many relationships. The personnel table has a one
field primary key.
I also have 25 reference tables (code, description) 21 of which have a many
to one relationship to the main Personnel table. All of these tables are
linked, via the Lookup Wizard, to allow combobox usage in forms and such.
I have used the Relationship tool to define all the relationships between
the tables in the database, enforcing RI with cascaded deletes and such
where appropriate.
I just tried to create another relationship for a new table to the main
table, and got the message that an "index cannot be created b/c there are
too many indexes on the Personnel table". Help says you can have 32 (which I
never really thought I'd EVER approach).
I have not explicitly created any indexes on the Personnel table, other than
the PK of course. But, when I search through the columns, I find 7 of them
(other than the PK) have "Yes (No Duplicates)" for the index property. When
I look at the Index tool, for the table, sure enough, there are 9 indexes.
That's the 7 additional fields, and index on the PK field and the PK
definition itself.
So, with all this information, here are my questions:
1) Where did the 7 indexes come from? Some are based on the reference
tables, some aren't, and I did not define them intentionally.
2) The field PersonnelID has and index AND shows up as the PK, in the
primary tool. Can I remove the "Yes (No Duplicates)" or does this really
need 2 indexes since it's the PK?
3) I assume creating the relationships to the table, in the relationship
tool, is creating an index. Is this true and can I do anything about it?
I have thought about splitting the table up into many smaller tables, but
don't really want to do that b/c the user likes the current user interface,
and splitting the able up now would mean more subforms in the UI and more
hassle for the user (since tabs don't work very easily to move between
fields with subforms).
I appreciate any thoughts and suggestions.
Larry
I have a Personnel table, with 4 child tables (location information,
compliance information, visa information, validation information for each
person) which are all 1 to many relationships. The personnel table has a one
field primary key.
I also have 25 reference tables (code, description) 21 of which have a many
to one relationship to the main Personnel table. All of these tables are
linked, via the Lookup Wizard, to allow combobox usage in forms and such.
I have used the Relationship tool to define all the relationships between
the tables in the database, enforcing RI with cascaded deletes and such
where appropriate.
I just tried to create another relationship for a new table to the main
table, and got the message that an "index cannot be created b/c there are
too many indexes on the Personnel table". Help says you can have 32 (which I
never really thought I'd EVER approach).
I have not explicitly created any indexes on the Personnel table, other than
the PK of course. But, when I search through the columns, I find 7 of them
(other than the PK) have "Yes (No Duplicates)" for the index property. When
I look at the Index tool, for the table, sure enough, there are 9 indexes.
That's the 7 additional fields, and index on the PK field and the PK
definition itself.
So, with all this information, here are my questions:
1) Where did the 7 indexes come from? Some are based on the reference
tables, some aren't, and I did not define them intentionally.
2) The field PersonnelID has and index AND shows up as the PK, in the
primary tool. Can I remove the "Yes (No Duplicates)" or does this really
need 2 indexes since it's the PK?
3) I assume creating the relationships to the table, in the relationship
tool, is creating an index. Is this true and can I do anything about it?
I have thought about splitting the table up into many smaller tables, but
don't really want to do that b/c the user likes the current user interface,
and splitting the able up now would mean more subforms in the UI and more
hassle for the user (since tabs don't work very easily to move between
fields with subforms).
I appreciate any thoughts and suggestions.
Larry