Discussion :

[CedricCrocetta]

Bonjour à tous,

Avant de commencer, je me présente rapidement puisque c'est mon premier message sur ce forum (mais pas ma première visite !) :
Je m'appelle Cédric, et travaille en tant que prestataire dans une entreprise pharmaceutique. Ma mission actuelle consiste à simplifier le fonctionnement du service dans lequel je suis affecté. Et une des phases de cette mission est la transformation d'un système "tentaculaire" actuellement géré via Excel en un système se basant sur un vrai modèle relationnel.

Et me voici donc sur votre forum, puisque, d'un niveau ~débutant sur Access, je bute depuis plusieurs jours déjà sur un étrange problème.

Je ne peux hélas pas mettre à disposition la base de données que je suis en train de construire, mais je vais essayer de vous détailler le plus clairement possible sa structure et mon problème :

Concernant la structure de la BdD : Des "Produits" sont identifiables par plusieurs items (nom, référence...), liés à des "Ateliers" (zones de fabrication) via une relation n-n. Ces "Produits" peuvent être rassemblés en "Spécialités" en fonction de leurs caractéristiques. Relation n-n entre "Produits" et "Spécialités". A leur tour, les "Spécialités" sont regroupés en "Noms Génériques" via une relation 1-n.
Pour chaque relation n-n j'ai crée une table de jointure.

J'ai crée un formulaire qui ressemble à ceci (certaines informations ont été masquées) :



[1],[2] et [3] : 'Module' de recherche des produits, en fonction du nom ou de la référence (Code SAP). [1] et [2] sont des zones de texte indépendantes. [3] est une zone de liste indépendante, issue d'une requête qui elle dépend des valeurs de [1] et [2]. [3] permet à l'utilisateur d'avoir une vue plus globale des produits similaires (ou du moins dont le nom est proche). [3] porte le nom "IdProduit", qui est le nom de la clef primaire dans la table "Produits"

[4] est un sous-formulaire tout simple issu de la table "Produits". Il est lié (Champs Père - Champs Fils) à [3] via "IdProduit". Ainsi, quand l'utilisateur clique sur une ligne dans [3], [4] se met à jour et affiche l'enregistrement lié. (Les boutons de navigation sont donc inutiles dans ce contexte puisque le sous-formulaire [4] n'affiche qu'un seul enregistrement). [4] est en lecture/écriture

[5], [6] et [7] sont des sous-formulaires issus des tables décrites précédemment. [5] et [6] sont en lecture/écriture, [7] est en lecture seule.

[8] est un bouton qui doit afficher dans [4] un nouvel enregistrement. J'ai utilisé deux méthodes différentes pour ce bouton, qui aboutissent au même problème :
1/ Sélection de [4] - Sélection d'un nouvel enregistrement. La clef primaire de "Produit" [3] affiche bien (Nouv.)
2/ Valeur de ([3]) "IdProduit" = "" (Chaîne vide). La clef primaire de "Produit" [3] affiche bien (Nouv.)
Dans la méthode 1/, un premier problème se présente : les sous-formulaires [5], [6] et [7] conservent la liaison à l'ancien "IdProduit", et cela m'embête.
Dans la méthode 2/, un autre problème se présente : pour ajouter des informations dans les formulaires [5] et [6], je suis obligé d'afficher un autre produit (via [3]) et revenir sur l'enregistrement.

Mais dans tous les cas, le problème le plus important est ce message qui apparaît quand j'entre une information dans un des champs de [4] :



Il ne me semble pas être dans une des trois conditions décrites par le message :
*J'ai bien vérifié, les modifications sont autorisées dans le formulaire ET le sous-formulaire
*Je suis bien en mode "Formulaire"
*Quel que soit le champs, quelle que soit la valeur entrée ce message apparaît.

D'après mes recherches, ce problème apparaît quand la liaison entre le formulaire et le sous-formulaire n'est pas faite. Hors ce n'est pas le cas ici.
La bizarrerie de ce problème est, qu'après avoir cliqué sur "Ok", je peux rentrer les informations que je veux, et valider l'enregistrement.
J'ai également remarqué ceci :
[4] prêt pour un nouvel enregistrement. "IdProduit" est bien à (Nouv.).
J'entre une valeur quelque part, le message d'erreur apparaît. Je clique sur OK et peux continuer à entrer des informations. "IdProduit" change bien puisque c'est un NuméroAuto (par exemple 464).
Si j'appuie sur "Echap" avant la validation de l'enregistrement, les champs se réinitialisent, "IdProduit" affiche (Nouv.). # Si je rentre tout de suite de nouvelles informations, je n'ai pas le message d'erreur et "IdProduit" s'incrémente de nouveau (465). (Même comportement si j'appuie sur le bouton [8] au symble #)
Par contre, si je sélectionne un produit via [3] et reclique sur [8], le problème réapparaitra.

Voilà, j'espère avoir été le plus clair possible dans l'explication de mon problème.

D'avance merci pour vos pistes !
Cédric

[loufab]

Bonjour,

Apparamment 4 est le centre de ton dispositif, c'est lui qui sert à créer et modifier... Alors pourquoi l'avoir mis dans un sous-formulaire et non dans le formulaire principal ?

Ceci étant lorsque tu as ce message as-tu tenté de faire un ctrl+pause ? Voir si une ligne de code est concernée.
S'il n'y a pas de code qui apparaît c'est que cela vient de la source et/ou du montage/interaction entre les contrôles.

Comme je le mets dans ma signature, je ne pratique pas les arts divinatoires, donc ce n'est qu'une piste que je te donne sans plus. Il faudrait voir ce formulaire avec ses dépendances et les tables associées même sans données.

Cordialement,

[CedricCrocetta]

Bonjour,

Apparamment 4 est le centre de ton dispositif, c'est lui qui sert à créer et modifier... Alors pourquoi l'avoir mis dans un sous-formulaire et non dans le formulaire principal ?

Ceci étant lorsque tu as ce message as-tu tenté de faire un ctrl+pause ? Voir si une ligne de code est concernée.
S'il n'y a pas de code qui apparaît c'est que cela vient de la source et/ou du montage/interaction entre les contrôles.

Comme je le mets dans ma signature, je ne pratique pas les arts divinatoires, donc ce n'est qu'une piste que je te donne sans plus. Il faudrait voir ce formulaire avec ses dépendances et les tables associées même sans données.

Cordialement,

Bonjour loufab, et merci de t'intéresser à mon problème.

Oui, [4] est bien le centre du dispositif. Si je l'ai mis en sous-formulaire, c'est pour pouvoir utiliser le 'module' de recherche [1], [2] et [3] qui permet d'avoir une vision globale des produits similaires, et de pouvoir naviguer rapidement entre leurs enregistrements respectifs. (Par exemple, l'utilisateur cherche "Dane" dans [1], et les produits "Danette chocolat", "Danette café" ressortent via la zone de liste [3], il peut ensuite naviguer rapidement entre les deux résultats trouvés). S'il est possible d'avoir le même fonctionnement en transposant [4] en formulaire, alors je me pencherai dessus.

La base est au travail, j'essayerai donc dès demain la combinaison ctrl + pause.

J'ai refait, de mémoire, les relations entre les bases :



Pour les relations entre Produit et j_ProdSpec, et Produit et j_ProdAtelier la relation est de type 'OUTER LEFT JOIN' (tous les enregistrements de Produit dans les tables de jonction). J'ai fait ceci afin de simplifier mes requêtes (puisqu'Access ne me laisse pas, dans l'interface de création des requêtes, la possibilité de gérer plusieurs relations externes en une fois).

J'ajouterai plus de précisions lundi, notamment pour les relations entre les contrôles des formulaires.

Bonne fin de weekend

[CedricCrocetta]

Bonjour,

Ci-dessous une capture d'écran afin de détailler les relations entre les contrôles des formulaires :



Pour expliciter un peu plus :

- L'utilisateur dispose de deux champs de recherche : un via le nom du produit, un via la référence du produit

- Ces deux champs sont "liés" à deux champs masqués (via une formule dans les champs cachés). Ces champs masqués ajoutent des astérisques avant et après la valeur du champ correspondant.

- La zone de liste [3] (cf. premier message) est issue d'une requête paramétrée, qui va chercher la valeur de ces champs masqués. La requête affiche, dans la zone de liste, tous les enregistrements (donc une clef primaire par ligne) de ma table "t_Produits". Au clic dans cette zone de liste un enregistrement est donc sélectionné (une seule clef primaire - "IdProduit" dans la table "t_Produits"). La zone de liste [3] porte le même nom que la clef primaire associée dans la table : "IdProduit"

- Le sous-formulaire est lié via un champs père-fils à [3] (IdProduit - IdProduit). Donc à chaque clic dans [3], l'enregistrement sélectionné change, et le sous-formulaire se met à jour.


Si je supprime cette relation père-fils, je n'ai plus le message d'erreur. Par contre je ne sais, dans ce cas, pas afficher dans [4] l'enregistrement associé à celui sélectionné dans [3].

[loufab]

Bonjour,

Tu pourrais redéfinir la source du 4 lors de la sélection de l'enregistrement dans 3.

Par exemple en mettant un peu de code dans l'événement sur clic de la liste 3.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Me.sousform4.Form.Recordsource = "SELECT * FROM Table4 WHERE id4=" & Me.liste3.Column(0) & ";"

ou 0 est le N° de colonne de l'id.

Ainsi à chaque clic dans la liste 3 tu affiches le bon enregistrement dans 4.

Cordialement,

[CedricCrocetta]

Bonjour,

Après une petite semaine loin d'Access (histoire de me changer un peu les idées !), j'ai essayé ta solution, Loufab, et elle marche nickel !


J'ai également testé la méthode 'DoCmd.SearchForRecord' qui donne aussi de bons résultats. Le problème est que du coup, l'utilisateur peut naviguer dans tous les enregistrements sans passer par la zone de liste [3]. La solution proposée par Loufab est donc plus adaptée.

Je passe donc le sujet en résolu.

Bonne soirée, et encore merci pour le coup de main !

[loufab]

Le search, comme son nom l'indique recherche l'enregistrement et s'y positionne dessus, libre à l'utilisateur de naviguer ailleurs.

La redéfinition de la source pose un filtre (idem à filter filteron) qui ne peut être contourné par l'utilisateur.

Dans le cas du filter, filteron (voir ces 2 propriétés) on peut casser le filtre via une action programmée sur un évenement (filter = false), l'avantage est que l'on ne réinterroge pas la bd (comme avec la redéfinition de la source) mais on récupère un gros volume de données (gain d'un coté/perte de l'autre).

En cas de gros volume de données, ou de base de données déportées, cela peut donner des résultats différents en terme de perfo et d'encombrement réseau.

A voir dans le temps.

[CedricCrocetta]

Merci pour le complément d'informations.

La base de données ne sera pas énormément volumineuse. En revanche les requêtes sont (très) complexes et impliquent de nombreux produits cartésiens et de regroupement. Il vaudra mieux, je pense donc, utiliser le filter filteron (si j'ai bien compris).

Bonne soirée

[loufab]

En effet, dans ce cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Me.sousform4.Form.Filter = "id4=" & Me.liste3.Column(0)
Me.sousform4.Form.FilterOn = True

Pour annuler l'action du filtre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Me.sousform4.Form.FilterOn = false