Discussion :

[vregn]

Bjr à tous,

Je me permets de poster un message car j'ai des difficultés à comprendre clairement comment créer des relations entre des tables avec des clé primaires (multi-champs).

L'idée générale est de créer un formulaire de saisie des données avec des tables liées, renseignées par des fournisseurs (essieux, axes d'essieu et roues).

Vous trouverez en PJ la vision de type association-entité (enfin ma vision....).

Je sais qu'une clé primaires multi-champs d'une table doit être composée de clés étrangères qui sont clés primaires d'autres tables.
Ceci dit, je n'arrive pas à appliquer ce principe au modèle de la PJ.


C'est pourquoi, je serais réconnaissant si qqn pouvez m'éclairer sur le sujet.

Dans l'attente de vous lire.

D'avance merci.

vregn

[loufab]

Bonjour,

Je ne comprends pas bien le problème. Dans ton modèle je vois des N° de série (essieu, axe, roue), ces N° sont uniques habituellement. Dans ce cas pourquoi vouloir rajouter des clefs supplémentaires à la liaison ?

Par contre à aucun endroit je ne vois d'ID pour identifier l'enregistrement de manière unique. C'est le B-A BA dans la construction d'une table... Avant même de penser information, il faut penser colonne ID. Cet ID est généralement utiliser pour faire des liaisons (rapidité, simplicité, robustesse).

Cordialement,

[vregn]

Bjr loufab,

Merci de ton retour.

Effectivement, je me suis dirige dans une mauvaise direction....
Hier, j ai construit les relations entre essieu, axe et roue via les id unique - NumAuto.
En revanche, ma contrainte sur l unicite des composants je l ai resolue via du codevba empechant la saisie dans le formulaire si les champs sont identiques.

Dans ma construction, l unicite de l essieu n est pas assure uniquement par le Numero de serie.
En effet, 1 essieu est unique de part : le fournisseur (FNR_ESSIEU), type (TYPE_ESSIEU) et le numéro (NUM_ESSIEU).

Tes remarques sont pertinentes j ai voulu complique les choses (erreur de debutant!) le BABA est gage d efficacite.

Encore merci.

VR

[loufab]

Bonjour,

Il me semble que tu confonds relations entre tables et absence de doublons. Il s'agit de 2 choses différentes.

Pour éviter les doublons avec des champs multiples il y a comme tu l'as fais le contrôle à la saisie.
Il y a une autre méthode plus académique, c'est d'utiliser des index à clefs multiple, puis de gérer l'erreur dans le form_error.

Cordialement,

[vregn]

Bjr Loufab,

J'ai essayé de comprendre ton conseil sur : "des index à clefs multiples, puis de gérer l'erreur dans le form_error" pour aller au fond des choses.

En revanche, je ne comprends pas comment l'utiliser.
En effet, lorsque j'ai essayé de mettre les champs suivants: le fournisseur (FNR_ESSIEU), type (TYPE_ESSIEU) et le numéro (NUM_ESSIEU) en index, l'unicité se fait sur le champ en lui même et non sur la combinaison des champs {FNR_ESSIEU, TYPE_ESSIEU, NUM_ESSIEU}.

En effet, mon NUM_ESSIEU peut ne pas être unique mais sa combinaison avec le TYPE_ESSIEU et FNR_ESSIEU l'est.

Ai-je bien compris le fonctionnement des index ou il y a qqchose que je n'ai pas saisie?

Encore merci de ton éclairage d'expert.

VR

[loufab]

Bonjour,

Voici comment se présente la fenêtre des index avec un multichamp.



Les colonnes (nom, prenom) s'enchainent les une au dessous des autres sous la même étiquette ( indexMultiple) et Unique est réglé à Oui.
Ignorer les nulls est un bon réglage pour améliorer les perfo.

Cordialement,

[Tofalu]

Sur Access 2010, vous pouvez aussi utiliser les macro de données AvantMaj