Discussion :

[HenriJ]

Bonjour,

Je suis confronté à un bug assez bizarre. J'ai codé ma base de données avec des sigles du type "CPGN", "IRS", etc.

Lorsque je faisais une requête (qui appelle une table 1, une table 2, et une table de jonction entre T1 et T2), j'obtenais a priori le bon nombre d'enregistrement pour "IRS", mais j'obtenais quasiment l'intégralité des enregistrements pour "CPGN" (alors qu'il ne concerne que 70 enregistrements sur 130 !).

Je me suis dis que, puisque le bug semblait avoir lieu essentiellement avec "CPGN", j'allais le remplacer par "TGT". En faisant les remplacements un-par-un (pour plus de contrôle), je me suis aperçu; qu'en outre, une dizaine de "CPGN" n'ont pas été détectés, donc n'ont pas été remplacés par "TGT". C'est moi qui l'ai fait manuellement.
A ce moment là, je n'étais plus dans la requête basée sur la jonction, mais directement dans T1. Les éléments "CPGN" qui n'ont pas été détectés n'avaient pas de "formes" particulière, du type "CPGN," donc on ne peut incriminer les virgules ou autres formes de ponctuation. J'ai commencé à faire des tests. J'ai copié-collé la base. Puis j'ai fais le même changement en passant par "remplacer tout", plutôt que le faire un par un. Apparemment, tout est oK.

Mais ce qui me pose vraiment souci, j'insiste, c'est que la requête bug pour "CPGN" et pas pour "IRS". Quelqu'un aurait-il une explication liée à la chaîne de caractère, ou autre ? Et comment savoir si je ne vais avoir le même problème avec d'autres codes ?

Je vous remercie par avance.

[jimbolion]

HenriJ,

Peux tu poster ta requête s'il te plait !

As tu dans ta table des champs null sur certains sigles (en utilsant nz dans ta requête tu devrais dans ce cas résoudre ton problème).

JimBoLion

[HenriJ]

Bonjour Jean-Marie,

Avant que tu ne continues, sache que j'ai changé mon codage ("CPGN" est devenu "TGT") et que cela fonctionne dorénavant. Il n'y a donc plus nécessité de résoudre le problème.

Non, je n'ai aucun "champ null sur certains sigles" car je n'ai aucune condition dans ma requête. Celle-ci est elle même basée sur une requête (intitulée "DTC/X = Ensemble des produits - (dépendent de MERE EXCLUE)"), dans laquelle il n'y a aucune valeur nulle. Certains enregistrements de la table mère (sur laquelle se base la requête initiale) sont vides.

Désolé je travaille en QBE et je n'ai pas le réflexe SQL:

SELECT [DTC/X = Ensemble des produits - (dépendent de MERE EXCLUE)].*, [DTC/X = Ensemble des produits - (dépendent de MERE EXCLUE)].[Type de compagnie d'ap info sur le Web]
FROM [DTC/X = Ensemble des produits - (dépendent de MERE EXCLUE)]
WHERE ((([DTC/X = Ensemble des produits - (dépendent de MERE EXCLUE)].[Type de compagnie d'ap info sur le Web]) Like "*" & [IRS] & "*"));

Henri
PS: mes excuses pour mon manque de réactivité

[jimbolion]

Henri,

En affichant la requête dans le mode SQL sous le QBE tu obtiendras le résultat officiel de la représentation SQL, et eventuellement une copie d'écran en mode création m'aiderait (visu des tables, jonction et champs) car je suis certain que ton problème est facilement décelable. Peux-tu essayer de faire une requête mise à jour de la table mère en remplaçant tous les champs que tu estimes vide en champ vide. Dans ton critère mettre est null (cf piece attachée ci-dessous).

Tiens moi au courant

JimBoLion

[HenriJ]

quote: "Peux-tu essayer de faire une requête mise à jour de la table mère en remplaçant tous les champs que tu estimes vide en champ vide."

Tu veux dire que, dans ma table je mets 0 à la place de laisser des champs vides (ou null) ? Je viens d'essayer, cela ne fonctionne pas lorsque je reviens aux requêtes qui portent sur "CPGN".

Je précise que le bug signalé au niveau de la requête impliquant la jonction (à savoir que la requête me sort la quasi intégralité des enregistrements) existe également si je fais une simple requête sur la table d'origine (). Lorsque je parlais, plus haut (message d'ouverture de ce post), du problème de défaillance du remplacement automatique des "CPGN" par des "TGT", j'étais bien à ce moment là dans la table d'origine.

De mon côté, j'hésite à passer sur un autre logiciel pour faire mes requêtes et mes tests statistiques (pour d'autres raisons que ce seul bug), donc je ne suis pas sûr que la résolution de ce post soit forcément nécessaire (il semble parfois difficile d'identifier parmi les posts déjà résolus ceux qui correspondent à notre problème; par exemple "bug de requête", le titre de mon post, ou encore les mots-clefs qu'il contient, ne veulent pas dire grand chose...).

Henri
PS: encore mes excuse pour mon manque de réactivité mais hier soir, je n'avais pas la version sauvegardée avec le bug.

[jimbolion]

Henri

quote: "Peux-tu essayer de faire une requête mise à jour de la table mère en remplaçant tous les champs que tu estimes vide en champ vide."

Je voulais dire les champs que tu estimes vides sont peut-être null (en remplaçant les valeurs nulles par des valeurs vides on élimine les interprétations des requêtes erronées)

Tu veux dire que, dans ma table je mets 0 à la place de laisser des champs vides (ou null) ? Je viens d'essayer, cela ne fonctionne pas lorsque je reviens aux requêtes qui portent sur "CPGN".

Si ton champ est de type texte tu remplaces comme dans mon exemple la valeur null par une valeur de type "", si le champ est numérique par une valeur 0.

De mon côté, j'hésite à passer sur un autre logiciel pour faire mes requêtes et mes tests statistiques (pour d'autres raisons que ce seul bug), donc je ne suis pas sûr que la résolution de ce post soit forcément nécessaire (il semble parfois difficile d'identifier parmi les posts déjà résolus ceux qui correspondent à notre problème; par exemple "bug de requête", le titre de mon post, ou encore les mots-clefs qu'il contient, ne veulent pas dire grand chose...).

Là tu es seul juge, mais en l’occurrence il ne s'agit pas d'un bug (actuellement des solutions plus ou moins d'envergure fonctionnent sous Access et avec des requêtes tout à fait stables), et là je parle en connaissance de cause.

PS: encore mes excuse pour mon manque de réactivité mais hier soir, je n'avais pas la version sauvegardée avec le bug.

Tu n'as pas à t'excuser, il m'arrive de recevoir des réponses plusieurs jours voire semaines après le dernier message.

Alors une petite explication :

je vois dans ta requête dans les filtres comme "*" & [DTC] & "*", cela sous entend qu'à chaque lancement de requête on t'invite à saisir la valeur correspondante à modalité de vente puis comme "*" & [X] & "*" la valeur de type de produit et enfin "*" & [CPGN] & "*" le type de compagnie.

PEux tu supprimer par exemple les 2 premiers filtres (faire une copie de ta requête) et passer un seul filtre du type "*CPGN*". L'utilisation de * avant et après cpgn implique que cpgn peut être contenu dans le nom (ex. aacpgn, cpgno, cpgn, ffcpgnyu sortiront dans ta requête). Essaies donc ensuite "CPGN". En y allant pas à pas tu rajoutes des filtres supplémentaires jusqu'à déterminer la nature du problème.

Jean-Marie

[HenriJ]

Ak, ok, je ne connaissais pas les requêtes "mises à jour" et n'ai pas vu la ligne "Mettre à jour" dans ta capture ("i.e. pas pris le temps de la voir!") , donc j'avais tout remplacé manuellement...

J'ai rebasculé sur l'ancien codage (qui ne mélange pas des valeurs numériques et du texte !!!). Au passage, la plupart de mes champs sont en mode "Mémo". Faut-il que je crée une variable en mode "Texte" pour y mettre uniquement mes codes ? Le mode mémo est-il source de conflit pour les requêtes, d'un point de vue général ? (je suis sûr de la qualité du codage, donc là je ne parle pas du problème de codage de type *CPGN* et "CPGN", mais bien vu et merci). La question du mode "Memo" était déjà apparue, lointaine, "à l'horizon", lors d'un ancien post.

Pour la réactivité, c'était pour t'éviter d'avoir à relire (et donc doubler le temps de travail), même s'il est clair que l'auteur du post peut s'être entretemps engagé dans d'autres tâches tout aussi prenantes.

[jimbolion]

Henri,

J'ai rebasculé sur l'ancien codage (qui ne mélange pas des valeurs numériques et du texte !!!). Au passage, la plupart de mes champs sont en mode "Mémo". Faut-il que je crée une variable en mode "Texte" pour y mettre uniquement mes codes ? Le mode mémo est-il source de conflit pour les requêtes, d'un point de vue général ? (je suis sûr de la qualité du codage, donc là je ne parle pas du problème de codage de type *CPGN* et "CPGN", mais bien vu et merci). La question du mode "Memo" était déjà apparue, lointaine, "à l'horizon", lors d'un ancien pos

Oui je sais j'étais intervenu sur ce post ! De mémoire le problème ne venait pas de là (mais des champs Null (utilisation de Nz pour pallier ce problème : oui on en reviens !) ! Donc pour un memo tu considères le champ effectivement comme du texte soit ""

donc si je comprends la valeur CPGN est inscrite dans le champ mémo. Donc procèdes pas à pas en omettant la variable dans un premier temps "*cpgn*" puis un deuxième filtre puis un troisième en contrôlant à chaque étape la cohérence des infos. Si tout est ok c'est que le pb venait bien des champs null (il ne te reste qu'à remettre tes variables si nécessaire : qui tomberont un jour probablement par une référence aux filtres spécifiés dans un formulaire).

Jean-Marie

[HenriJ]

Oui, la valeur CPGN est dans une variable "Memo", parmi beaucoup d'autres signes. Jusqu'ici, cela n'avait jamais posé de problèmes (quasiment toutes mes variables sont en mémo). Il n'y a pas de champ null, c'est sûr et certain (c-à-d des champs avec "0"), d'autant plus depuis que j'ai fais la mise à jour.
Il y a des champs vides et depuis que je les ai codée en valeur numériques, puis repassé en champs vides, je n'ai pas testés de mettre une valeur texte (par exemple "vide") pour voir si c'était ça le problème...

En ce qui concerne le filtre unique, oui, je l'avais testé, désolé de ne l'avoir pas précisé, je pensais joindre la photo en capture d'écran, à la place de celle que j'ai mise plus haut. Là Pièce jointe 139913.
Question résultats:
- lorsque je cherche uniquement *CPGN* dans la table mère (tous les autres filtres étant exclus), j'obtiens 278 (autant que d'enregistrements dans la table mère).
- lorsque je fais une requête sur une requête, c-a-d que je cherche *CPGN* dans une requête (qui inclus les autres filtres), j'obtiens 210 (autant que d'enregistrements dans la requête "mère").

henri
PS: je ne comprends pas " qui tomberont un jour probablement par une référence aux filtres spécifiés dans un formulaire".
Jusqu'ici je n'utilise pas de formulaire, je suis seul utilisateur de la base et je travaille directement dedans. Ne te compliques pas à m'expliquer s'il n'y a pas d'enjeu pour la résolution de ce poste.

[jimbolion]

Henri,

Oui de plus en plus étrange en effet !

La pièce jointe n'est à priori pas conforme ?

Sauf données confidentielles (voire à épurer), j'aimerai bien travailler sur ta base !

JimBoLion

[HenriJ]

Voilà la re-.

Pour tester de mettre quelque chose dans les champs vides, j'ai tenté une mise à jour avec:
critère: ""
Mettre à jour: "vide"

Toutes les données, toutes, même celles qui ont du texte (les CPGN, IRSC, etc.) on été remplacées par "vide". Peut être est-ce le champ "mémo" qui pose problème, et qu'il me faut créer obligatoirement des variables texte ou numériques pour faire des requêtes. Si c'est le cas, probablement cette réponse existe déjà dans les forums. J'ai commencé à explorer, mais je ne trouve pas grand chose en lien avec mon problème.
Ex:
Quelles sont les limites des champs de type Mémo dans une requête ?
Dans une requête avec regroupement des données, les champs de type Mémo sont tronqués à 255 caractères et convertis en champs de type Texte.

Dans tous les cas, je vais opter pour travailler plus lentement, mais plus sûrement. D'autant plus que dans certains cas, lorsqu'il manque des données (i.e. des champs vides... ce qui n'était pas le cas avec ma requête de requête jonction), il est bon de les distinguer des champs nuls. Notamment pour faire des tests statistiques qui prennent en compte l'absence de données (les "n.a", pour "non available" sont pondérés dans le calcul).

Mes données ne sont pas confidentielles (c'est simplement un travail en cours), mais je manque cruellement de temps pour prendre une décision, donc je préfère aller au plus simple et ne pas les envoyer. Probablement je reviendrai vers toi dans un an, pour te les envoyer.

J'en profite pour te remercier de ces longs échanges, ici et ceux des précédents posts.

[jimbolion]

Henri,

Comme tu veux, quelques essais sont à effectuer... je suis surpris des résultats, je m'étonne et voulais comprendre.

Je vais prendre le temps d'analyser çà tranquillement les jours prochains

JimBoLion

[HenriJ]

Pour tester avec quelque chose dans les champs vides, j'ai tenté une mise à jour avec:
critère: ""
Mettre à jour: "vide"

Autant pour moi, cette manip fonctionne. J'arrive sans problème à passer les champs vides (i.e. "") en "vide", et à faire la manip inverse. Les autres enregistrements ne sont pas touchés, mais sont reportés tout en bas du champ.

Mais dans tous les cas, le résultat est toujours le même, c'est l'intégralité des enregistrements qui est présenté par la requête (110 lignes), lorsque je lui demande les CPGN (70 lignes).

[jimbolion]

Henri,

Si tu as un peu de temps prépares moi un de ces jours ta base avec la requête. Je vais regarder çà.

De mon côté je vais effectuer des tests sur la zone mémo mais je pense que de ce côté çà devrait marcher (j'ai jamais eu de problèmes dans l'extraction d'infos de mes champs mémos).

Jean-Marie