“Trop d'index sur la table” erreur lors de la création de relations dans Microsoft Access 2010
J'ai tblUsers qui a une clé primaire du nom d'utilisateur.
Nom d'utilisateur est utilisé comme clé étrangère dans de nombreux tableaux. Dans un tableau, il est utilisé comme une clé étrangère pour de multiples domaines (par exemple, ObserverID, RecorderID, CheckerID).
J'ai ajouté avec succès les relations (dans la MS Access "Relation"), où j'ai des alias de table à faire de multiples relations par table:
*tblUser.Nom d'utilisateur -> 1 à plusieurs -> tblResight.ObserverID
*tblUser_1.Nom d'utilisateur -> 1 à plusieurs -> tblResight.CheckerID
Après la création d'environ 25 relations avec l'application de l'intégrité référentielle, lorsque j'essaie d'ajouter un autre, j'obtiens l'erreur suivante:
"L'opération a échoué. Il y a trop d'indices sur la table 'tblUsers.' Supprimer une partie de l'index sur la table et recommencez l'opération."
J'ai couru le code que j'ai trouvé ici et elle revint que j'ai 6 index sur tblUsers. Je sais qu'il ya une limite de 32 index par table.
Suis-je à l'aide de la relation de GUI de mal? Access créer un index pour l'application de l'intégrité référentielle chaque fois que je créer une relation (en particulier les indices qui ne tourne pas lorsque j'ai exécuté le script)? Je suis un peu perplexe, toute aide serait appréciée.
OriginalL'auteur avianattackarmada | 2010-12-27
Vous devez vous connecter pour publier un commentaire.
Bon, après avoir fait un peu plus de recherche, je pense que j'ai eu la réponse à cette question. Apparemment c'est un très plafond commun avec l'accès. Je vais résumer ce post j'ai trouvé ci-dessous:
Chaque table ne peut avoir 32 'contraintes'. Chaque indice et de l'application de l'intégrité référentielle (RI) compte pour cette 32. MS Access crée automatiquement une contrainte lorsque vous sélectionnez appliquer RI; vous ne pouvez pas désactiver cette option.
Tout le code snipets et les choses que j'ai trouvé grâce à google, retourné que j'ai eu six index sur la table (et donc j'ai été confus). Ce que je n'étais pas à trouver/ne savais pas c'est que mon de 25, les relations ont été comptés à l'encontre de mes 32, parce que j'avais RI appliquée.
Ma solution a été de laisser tomber RI sur le "moins prioritaires" fields (cela me fait mal de dire ça), et de "faire respecter" les formes d'entrée de données.
En gros, c'est une raison de plus je suis de la migration de l'accès et dans PostgreSQL peu de temps.
Si quelqu'un a une meilleure contourner, j'aimerais ici. Merci.
Il n'y a aucune raison de croire que le fait d'avoir 25+ index indique une table dénormalisée. En fait, la normalisation conduit à PLUS d'indices en raison de contraintes de clés étrangères. Les OP pourraient avoir une table avec 25 champs de chacune des clés étrangères dans 25 tables distinctes. Il est assez facile d'imaginer un objet qui a 25 différents, indépendants des propriétés qui peuvent être représentés comme des indices dans 25 tables distinctes, sans "perte de normalisation". Si c'est le cas, comment voulez-vous suggérer que l'on traite le problème? Diviser le tableau en deux 1:1 tables? Pas une solution idéale.
OriginalL'auteur avianattackarmada
Votre table a caché des indices qui ont été créés lorsque vous avez défini vos relations. Les noms pour les indices de commencer avec le "~" caractère. Mais le code que vous avez trouvé ignore les indices cachés à cause de cette expression:
Vous qui pourrait faire ListIndexes() fonction sont cachés les index en modifiant cette ligne:
Aussi, vous pouvez vérifier le nombre total d'index de votre table avec cette instruction dans la Fenêtre exécution:
OriginalL'auteur HansUp
Vous pouvez obtenir une liste de tous les indices, y compris ceux qui sont cachés, avec les éléments suivants:
Qui donne
Noter que si vous avez des champs à valeurs multiples dans une table, chacun aura un indice caché.
OriginalL'auteur Brian Burns
Il est assez ancien, mais le problème reviens très souvent et ce fil vient en premier dans les moteurs de recherche (quelqu'un m'a dit 😉 )
Une bonne possibilité de surmonter ce problème est de travailler avec un "helper" Table de lien vers d'autres Tables.
Un exemple:
Un Article de la table est liée à beaucoup d'autres tables pour des raisons différentes. Aussi elle peut avoir besoin de beaucoup de clés étrangères pour lui-même. Une telle table reçois très souvent possible d'index. Je dois aussi avoir trois ou quatre d'entre eux dans mes plus gros projets.
À presque le double de la possible RI Jointures/index vous pouvez travailler avec un assistant de table qui a un rapport de 1:1 RI se Joindre à la table tblArticle avec juste l'Unique Identificateur de Champ. Je ne nom de le même pas avec shortletter fk en Face d'elle comme je le ferais normalement. Appelons ça de la tblArticleLinker.
Chaque table qui devient une Clé étrangère de tblArticle, par exemple, un Ordre de Position, son rejoindre dans la tblArticleLinker.
--> Vous ne le lâche un indice pour tous ces liens, juste un à la Linkertable
La seule chose que vous devez vous assurer, c'est que vous ajoutez toujours la clé de la linkertable lors de l'enregistrement, sinon il n'est pas possible d'utiliser l'Enregistrement.
D'un tel tableau est - de mon expérience - beaucoup plus facile à manipuler que l'approche habituelle de diviser les champs dans des tables différentes. Dans les Requêtes, vous n'avez pas particulièrement besoin de la helpertable (parfois les requêtes sont plus rapides si vous le faites), vous pouvez accéder directement à la table. Il n'est pas fait automatiquement, comme d'habitude.
Tipp: Même approche peut également être utilisé pour s'assurer, que seuls les "libérés" des Enregistrements peut être utilisé par l'utilisateur. Ou simplement l'utiliser comme une unité de Filtre. Cela aide à surmonter d'éventuelles Logiciel de Bugs qui ne suivent pas la logique de ce qu'ils devraient.
OriginalL'auteur Hansi Meier