Look-up vs relation de Microsoft Access

Je suis l'élaboration d'un Microsoft Access 2013, en fonction du système d'information.
L'une des exigences du client était de simplifier le processus de saisie de données par l'utilisation de zone de liste déroulante avec les valeurs disponibles.

Par exemple, au lieu d'entrer agentID le client a demandé à permettre à l'utilisateur de choisir le nom de l'agent dans la liste déroulante, la même logique avec d'autres domaines similaires.

En bref:

J'ai besoin d'éviter autant que possible le besoin d'entrer les valeurs de l'ID et de laisser à l'utilisateur de choisir dans la liste déroulante.

Microsoft Access est doté d'un assistant de recherche qui permet à l'utilisateur de lier les champs de la table avec un champ spécifique à partir d'une autre table, par exemple, de lier cityID de tblVoyage avec tblCities/cityID par l'assistant liste de choix, et de laisser l'utilisateur choisir la ville dans la liste déroulante et non pas en tapant ville spécifique ID dans le champ.

Tout ce qui ressemble beaucoup, mais il y a une confusion moment.
Au cours de DB sûr, j'ai appris que dans le but de construire une base de données et de travailler avec elle, nous avons à définir les relations entre les tables (1:1, 1:M, M:N), mais si je le fais je ne peux pas utiliser l'assistant liste de choix, parce que j'ai déjà défini les relations entre les tables. Et, en conséquence, l'utilisateur doit saisir tous les codes manuellement, au lieu de les choisir dans la liste déroulante.

Donc, je veux:

De comprendre exactement quand dois-je utiliser l'Accès assistant de recherche et lors de la définition d'une relation entre les tables.
Comment correctement minimiser le nombre de fois où l'utilisateur doit saisir les données au lieu de choisir l'élément voulu dans la liste déroulante.

InformationsquelleAutor Mike B. | 2013-05-04

7

Le consensus général semble être ici que les champs de Recherche, doit être évitée. Ils sont vraiment simplement un raccourci pour avoir une "bonne" table de recherche et ils se cachent ce qui se passe réellement au niveau de la table. Par exemple, disons que vous avez un champ de Recherche pour [Taille] avec les valeurs de "Petit", "Moyen" et "Grand". Quand vous regardez le tableau, vous voyez le mots, mais les chances sont bonnes que le tableau contient réellement numéros de comme 1, 2, et 3. Vous allez à
```
UPDATE tblName SET Size="Large"
```
et la requête échoue, car il ce que vous devez faire est de
```
UPDATE tblName SET Size=3
```
(Lorsque vous maintenez un "bon" séparer le tableau de recherche de votre terrain dans le tableau principal qu'est-ce que fait dans le domaine: la pharmacocinétique de la valeur de l'élément sélectionné dans la table de recherche. Vous pouvez toujours concevoir vos formulaires d'avoir une zone de liste modifiable peuplée par la table de recherche et lié à un champ dans la table principale.)

Pour encore plus de confusion, l'assistant liste de choix offre une "autoriser les sélections multiples" l'option d'un champ peut contenir qu'une seule valeur (en quelque sorte). Qui a apparemment été ajoutée afin que l'Accès pourrait mieux travailler avec SharePoint, et c'est vraiment seulement moment où cette fonction doit être utilisée. Dans l'écrasante majorité des autres cas, c'est mieux explicitement maintenir un enfant séparé de la table pour stocker les sélections multiples.

Modifier

L'Assistant Zone de liste déroulante, vous guide à travers le processus de relier votre zone de liste modifiable à sa source d'enregistrement (la table de recherche) et la liaison de sa valeur à un champ dans votre table de données. Par exemple, disons que vous avez déjà mis en place une table de recherche pour [les Agents]
```
ID  AgentName
--  ---------
 1  Gord     
 2  Angie    
```
...et un tableau de données pour [Comptes]
```
ID  agentID  AccountName
--  -------  -----------
```
Vous créez un nouveau Formulaire avec les [Comptes] table comme Record Source. Quand vous allez à ajouter une Zone de liste déroulante du formulaire de l'assistant doit s'exécuter et vous demander "Comment voulez-vous que votre zone de liste modifiable pour obtenir ses valeurs?". Vous choisissez l'option "je veux la liste déroulante pour obtenir les valeurs d'une autre table ou requête."

Dans l'étape suivante, vous devez choisir les [les Agents] table:

Vous indiquez ensuite l'assistant que vous voulez afficher la [AgentName]:

Après vous choisir un ordre de tri (si souhaité), vous obtenez pour confirmer la largeur de la colonne(s). Le congé de "Masquer la colonne de clé (recommandé)" est activé.

Enfin, vous aurez à choisir ce qui arrive à la case de valeur. C'est là que vous "lier" à l' [agentID] dans le champ [Comptes] table:

Noter que la zone de liste déroulante afficher le [agentName] pour l'utilisateur de sélectionner, mais son .Value sera le numérique [Agents].[ID], et c'est ce qui va être stocké dans [Accounts].[agentID].
- Pourriez-vous préciser «Vous pouvez toujours concevoir vos formulaires d'avoir une zone de liste modifiable peuplée par la table de recherche et lié à un champ dans la table principale»? Exactement comment puis-je le faire? Il est codé en dur dans VBA ou un assistant ou quelque chose comme ça?
- Oui, l'Assistant Zone de liste déroulante, vous guide à travers le processus. J'ai mis à jour ma réponse à illustrer.
- Thompson Cela fonctionne bien pour une relation 1 à plusieurs , mais dans une relation plusieurs-à-plusieurs-dire les projets et les services - ce qui semble être vraiment impossible avec des contrôles d'accès. Un contrôle de zone de liste [DepartmentNames] qui remplit dans la Table intermédiaire avec projID, DepID, Affecté ,l'État est à la tête banger. Si vous avez des idées, je suis ouvert.
InformationsquelleAutor Gord Thompson

Vous devez vous connecter pour publier un commentaire.

Modifier