Discussion :

[NikoC]

Bonjour,

J'ai remarqué qu'Access autorisait les modifications de données directement par le biais du résulat d'une requête 1-N (i.e. on lance le requête, on clique sur une cellule (autre que le lien) et on en change la valeur), quitte à modifier automatiquement les autres cellules affichant en fait la même donnée par le jeu du 1-N.

Par contre Access semble ne pas autoriser la même facilité lors d'affichage du résultat d'une requête N-N... et ce même si l'on fixe la valeur de certaines clés pour en faire au bout du compte une relation 1-1.

Voici mon cas de figure (simplifié):
J'ai une table produits, dont la clé primaire est cad (code barre) et pays (en effet les stocks, les ventes différents d'un pays à l'autre)
J'ai une seconde table sélection dont la clé primaire est cad et utilisateur (là on ne tient pas compte du pays car lorsque qu'un produit est sélectioné, il l'est globalement).
Ma requête fait donc le lien entre ces 2 tables, sur le cad.
Ce que je voudrais est de pouvoir cliquer sur le champ bouléen de sélection, pour un produit/pays donné et que cela se répercute sur les autres pays de ce produit.
Mais cela m'est interdit.
Pourtant... dans les conditions d'utilisation, je fixe l'utilisateur et le pays, soit les 2 parties de clé "libres" de ma jointure. Je conçois qu'Access gère la clause Where après coup et maintienne sa restriction de non modification d'une N-N... mais je n'ai au bout du compte pas de solution...

Voici le même problème plus détaillé:
En fait, cette requête s'affiche dans une formulaire de sélection, et ma requête n'est pas une simple N-N entre 2 tables, mais 1-N et 1-N entre 3 tables: j'ai toujours ma table sélection (clé: cad/utilisateur), liée en 1-N à la table "produits infos communes" (clé: cad), elle même liée en 1-N à la table "produits infos locales" (clé: cad/pays).

Si cela est vraiment impossible de modifier en N-N, je me dis que ce n'est aps bien grave car il me suffit de selectionner dans une requête 1-N entre les tables selection et "produits infos communes", mais je vourdais tout de même qu'en face de ma case à cocher s'affichent toutes les infos de mon produits, même les infos locales.
Puis-je avoir 2 requêtes (1_N pour le coup) en source d'un seul formulaire, ou bien puis-je avoir 2 sous-formulaires d'un formulaire principal (dont je n'ai aps parlé mais c'est lui qui fixe l'utilisateur et le pays), chacun avec comme source une 1-N, mais tous les deux liés (même ordre d'affichage et "même ascenceur", de telle manière que mes lignes (2 demies-lignes) d'enreg soient cohérentes.

Merci beaucoup, ne serait-ce que pour le temps pris pour lire...

[Arkham46]

Bjr,

Par contre Access semble ne pas autoriser la même facilité lors d'affichage du résultat d'une requête N-N... et ce même si l'on fixe la valeur de certaines clés pour en faire au bout du compte une relation 1-1.

Qu'entends tu par "fixer la valeur de certaines clés"???

Pour qu'il y ait relation 1-1, il faut définir dans la table des index sans doublons.

[NikoC]

En fait, mes 2 tables dont les clés sont cad/utilisateur et cad/pays, sont liées dans une requête par cad, mais la close Where fixe utilisateur = currentuser() et pays à la valeur d'un élément présent dans un formulaire parent.
Au bout du compte j'ai donc "presque" une jointure 1-1, sauf que Access doit certainement toujours la considérer comme une N-N

[NikoC]

Bjr,



Qu'entends tu par "fixer la valeur de certaines clés"???

Pour qu'il y ait relation 1-1, il faut définir dans la table des index sans doublons.

Re,

Les index de toutes les tables sont sans doublons car il s'agit à chaque fois des clés primaires.

J'ai beau retourner le problème sous je ne sais combien d'angles (d'un point de vue requête, d'un point de vue formulaire ou sous formulaires, etc), je tourne en rond...

Un grand merci par avance à la bonne ame qui aura une solution...

[NikoC]

Bon bah ça n'a pas inspiré grand monde...

J'ai fini par trouver une solution, loin d'être idéale mais qui fonctionne.

Je suis parti de la réflexion:

"je ne vais tout de même pas travailler sur une macro-table contenant toutes les infos"

pour finir avec:

"avec une table faite de toutes les clefs et contenant tous les croissements possibles, liée avec toutes les tables initiales qui contiennent les details, je coupe la poire en deux: j'ai tous les croissements, qu'il me faut tenir à jour, mais ce n'est pas trop volumineux car le détail reste dans les tables éclatées et au bout du compte j'obtiens une requête dont le résutat est modifiable en live"

Merci à ceux qui se seront penché sur mon problème. Et... libre à vous de rouvrir un topic si une meilleure solution vous apparait