Incohérence dans les valeurs d'un champ entre un formulaire et une table

Bonjour

J'ai une base de données scindée en 2 fichiers.

Dans le formulaire principal de ma base, j'ai voulu enrichir la liste de valeurs proposées en intervenant directement dans l'un des contrôles (dans Données / Contenu). J'ai ainsi ajouté 3 ou 4 valeurs qui n'étaient pas présentes.

Or, désormais, quand je veux directement rajouter des données dans la table en mode "feuille de données", je ne retrouve plus aucune des valeurs de ma liste pour ce champ précis.

J'ai dû m'y prendre comme un manche mais je ne sais pas trop pourquoi...

Merci. :?

Bonjour.

Citation:

---

j'ai voulu enrichir la liste de valeurs proposées en intervenant directement dans l'un des contrôles (dans Données / Contenu).

---

Quel type de contrôle ? Liste déroulante ? Champ multi-valeur ? Liste ?

A+

Salut.

Je suppose que tu parles d'une combobox (contrôle de liste déroulante). A part pour un choix de type "oui / non" (et encore, parce qu'en Belgique, bilinguisme oblige, je passe par une table), je conçois toujours les combobox sur base d'une table et jamais sur base d'une liste de valeurs "en dur"... Du coup, il n'y a jamais de problème lorsqu'il faut ajouter des données puisqu'il suffit de les ajouter dans une table sans devoir modifier la structure.

Peux-tu préciser ton cas?

Oui, il s'agit bien d'une combo-box qui permet de choisir parmi une catégorie d'immeubles :

Pièce jointe 599163




Ce contrôle pointe vers une table :

Pièce jointe 599164




table dont les valeurs ont été stockées ici :

Pièce jointe 599165


Quel est le meilleur moyen pour mettre à jour cette liste de catégories ? Je voudrais rajouter "patrimoine", "enseignement", etc.

Merci pour votre aide.

Citation:

---

Envoyé par ncharles

[...]
Quel est le meilleur moyen pour mettre à jour cette liste de catégories ? Je voudrais rajouter "patrimoine", "enseignement", etc.[...]

---

Les valeurs que tu montres devraient s'appuyer sur une table plutôt que sur une liste de valeurs. Ce serait 1000 fois plus simple à gérer et ne demanderait pas de modifier ta structure pour un simple ajout... De plus, tu pourrais jouer à fond sur les liaisons entre tables pour créer tes formulaires/sous-formulaires, états/sous-états, requêtes d'analyse, etc...

Vois-tu comment procéder?

Non pas du tout... Si tu me l'expliquer en quelques lignes, je veux bien... :oops:

Tu as 3 petits cochons solutions:

1. La maison de paille: c'est ce que tu as fait jusqu'ici, à savoir mettre tes valeurs "en dur" dans la source du combobox;
2. La maison de bois: tu crées une table monocolonne dans laquelle tu renseignes éléments de la liste et elle alimente le combobox;
3. La maison de briques: tu crées la même table, mais tu ajoutes une clé primaire et tu "joins" les tables par une paire clé primaire/clé étrangère.

La maison de paille

Tu en as touché les limites. Il n'y a que des désavantages à pratiquer ainsi. La seule liste que je peux accepter ainsi serait la liste "OUI/NON" et encore. Comme déjà dit, en Belgique, on doit parfois développer en bilingue, voire en multilingue, et les textes en dur dans la structure de la base posent évidemment des problèmes dans ce cas. De plus, si la liste est utilisée à plusieurs endroits, il faudra modifier la liste partout où elle est utilisée. A abandonner à tout jamais!

La maison de bois:

Une table TypesBiens qui reprend simplement les valeurs saisies auparavant manuellement dans la liste. Dans la table des biens, on crée une liste déroulante qui s'appuie sur cette table en triant les données par ordre croissant.

Avantage: Si tu ajoutes une donnée dans la table des types de biens, elle sera disponible dans toutes les combobox qui s'appuient dessus. C'est l'avantage de passer par une table car tu ne dois plus modifier la structure de ta base. Il suffit de compléter la liste au fur et à mesure que tu ajoutes des types de biens, et la requête illustrée ci-dessous te les présente par ordre croissant.

Inconvénient: Si tu modifies un libellé dans la table des types de biens, cette modification n'impacte pas la table des biens (image du bas dans le triptyque ci-dessous. Ca va donc compliquer tes regroupements et donc tes analyses.

Pièce jointe 599188


La maison de briques:

Avec la maison de briques, tu fais de la vraie "base de données relationnelle" et c'est pour moi le seul modèle valable:

• Dans la table des types de biens, tu places une clé primaire autoincrémentée (entier long);
• Dans la table des biens, tu places une clé étrangère qui pointera vers la clé primaire de la table des types de biens;
• Idéalement, tu places l'intégrité référentielle pour assurer que les paires clé primaire / clé étrangère sont toujours valides;
• La requête qui alimente la liste dans la table des biens est modifiée pour récupérer la clé primaire (colonne liée = 1) et pour trier sur les libellés. Pour masquer la clé primaire à la saisie, on donne une largeur de 0 à la première colonne;
• Pour l'utilisateur, la mécanique est transparente, mais tu stockes en fait "le numéro" du type du bien dans la table des biens;
• De ce fait, si tu modifies un libellé, la clé numérique restant inchangée, le nouveau libellé apparait partout.

Avantages:

• Tu modifies les libellés facilement;
• Les indexations et les filtres sont très rapides;
• Ta base est plus légère car les clés prennent 4 octets là où la répétition de clés alphanumériques va faire grossir ta base;
• Tu peux créer facilement des jeux de formulaires/sous-formulaires;
• ...

Inconvénients: Pour moi il n'y en a pas. Avec un peu de pratique, ça devient un réflexe de "penser relationnel" et de "mettre en place le relationnel". Il faut juste penser que dans le champ TypeBienFK, c'est la valeur de la clé numérique qui est stockée, et donc en cas d'export vers Excel par exemple, il faut prévoir une requête qui unit les deux tables pour récupérer le libellé. Dans Excel, cela peut se faire avec Power Query qui "travaille en relationnel".

Pièce jointe 599191



Remarque: D'autres te proposeront une solution entre le bois et la brique, à savoir créer les paires clé primaire / clé étrangère sur le libellé. Ca résout le problème de la modification du libellé modifié. Je suis farouchement contre cette pratique. D'abord parce qu'elle ne permet pas une approche systématique de la modélisation des données (le comble en informatique!) puisque tu devras tout le temps vérifier les types et longueurs de tes clés pour les apparier alors qu'en choisissant des entiers longs, tu ne poses pas de questions, tu as une approche systématique et rigoureuse de la création des tes applications. Ensuite parce que sur de gros volumes, les performances pourraient se dégrader car il est plus coûteux en calcul de travailler avec des index alphanumériques qu'avec des entiers longs. Enfin parce qu'elle impose la mise à jours des clés en cascade lors de la modification d'un libellé, ce qui a également un coût.

Merci pour la réponse très détaillée.
Je vais essayer de mettre tout çà en œuvre sans me faire attraper par le méchant loup, et je te tiens au courant !

Par contre, j'ai une question de débutant : j'ai environ 4000 biens déjà recensés. Que va-t-il se passer lorsque je vais appliquer cette modification, mon champ "type de bien" comprenant déjà des valeurs alphanumériques (immeuble, maison de ville, villa, etc.) ?

Bonjour.

As-tu 4000 type de biens différents ?

Si oui, tu vas avoir des soucis avec la liste déroulante car elle sature aux alentours de 1000 valeurs, après elle devient simplement inutilisable même si elle ne plante pas l'appli.

Sinon si ton nombre de types est raisonnable, tu peux avoir des milliers d'enregistrements utilisant ce type il n'y aura pas d'impact puisque la liste ce base sur la liste des types qui reste globalement constant pas sur les enregistrements qui s'en servent.

A+

La liste déroulante n'est utilisée que pour sélectionner le type de bien, pas pour choisir un bien en particulier, donc pas de souci de ce côté-là.

Citation:

---

Envoyé par ncharles

[...]
Par contre, j'ai une question de débutant : j'ai environ 4000 biens déjà recensés. Que va-t-il se passer lorsque je vais appliquer cette modification, mon champ "type de bien" comprenant déjà des valeurs alphanumériques (immeuble, maison de ville, villa, etc.) ?

---

Si tu as déjà renseigné le type de bien comme alphanumérique dans la table des biens, tu vas devoir adapter pour une clé externe numérique via une requête de mise à jour, en faisant correspondre les enregistrements sur le libellé du type de bien. Il faut que les libellés soient les mêmes des deux côtés.

Peux-tu redonner une image des deux tables telles que modifiées?

Voici la table (évolutive) qui contient les types d'immeuble :

Pièce jointe 599544


et la table des immeubles avec le type toujours désigné sous une forme alphanumérique :


Pièce jointe 599545



Des suggestions pour la requête de mise à jour ? Merci encore pour ce coup de main.:P

Voici la requête

Pièce jointe 599548

La table t_immeubles avant et après. L'enregistrement encadré n'est pas mis à jour car la correspondance n'a pas été trouvée (problème d'espaces)

Pièce jointe 599549

Pièce jointe 599550

Bon, ça y est, je suis chaud. Trêve de procrastination ; je me décide enfin à réaliser cette modification de ma base !

Souci, Access me dit que je suis dans une "table liée" et qu'il faut que je travaille dans la base de données source. Le problème vient-il du fait que ma base est fractionnée ? :?