Discussion :

[GuiBar18]

Bonjour à vous,

Un petit problème se pose sur plusieurs de mes requêtes sélection : elles ne sélectionnent pas tous les enregistrements qu'elles devraient.

Par exemple cette requête :

Code :

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

1
2
3
4
5
[SQL]
PARAMETERS DateD DateTime, DateF DateTime;
SELECT Echeancier.N°Dossier, Pôle.Id_pôle, Etat_Avancement.[Etat d'avancement], Echeancier.IA, Left([codepostal],2) AS Dep, Clients.Client, Echeancier.Intitulé, Echeancier.[Type de marché], Echeancier.Date_Reponse, Donnes_Financière.Valeur_Globale, Donnes_Financière.Valeur_ajoutee, Echeancier.[Probabilité d'obtention], Echeancier.Concurent_Attributaire, Echeancier.Date_Commande, Echeancier.[Mt k€ HT], Echeancier.Date_Fin_Et
FROM Etat_Avancement INNER JOIN (Pôle INNER JOIN ((Clients INNER JOIN Echeancier ON Clients.N°Client = Echeancier.Client) INNER JOIN Donnes_Financière ON Echeancier.N°Dossier = Donnes_Financière.N°Dossier) ON Pôle.N°Pôle = Echeancier.Secteur_Activite) ON Etat_Avancement.N°Avancement = Echeancier.[Etat de l'Offre]
WHERE (((Etat_Avancement.[Etat d'avancement])="Gagné" Or (Etat_Avancement.[Etat d'avancement])="Perdu" Or (Etat_Avancement.[Etat d'avancement])="En-cours") AND ((Echeancier.Date_Reponse) Between [DateD] And [DateF]));

Elle devrait sélectionner 43 enregistrements, or je n'en obtient que 35. 7 enregistrements sont omis. Pourtant, lorsque j'examine de plus près ces enregistrements, ils sont remplis, dans le sens ou aucun des champs interrogés par la requête n'est vide.
De plus il ne forment pas des doublons avec les enregistrements déjà présents (les 35 qui sortent de la requête).
J'ai aussi contrôlé la validité des champs (qui sont de toutes façons saisis à l'aide d'un formulaire muni de sécurité sur le contenu). Les dates sont bien des dates, les nombres sont bien des nombres etc.

Au début je pensais que c'était un problème de la condition entre deux dates en me disant qu'il récupère un enregistrement par jour et pas plus, mais en mettant des dates bidons (2022) sur mes 7 enregistrements problématiques, il ne les sélectionne quand même pas (j'exécute entre 2021 et 2030 pour le coup).

En guise d'exemple, le fichier Excel ci-joint : l'enregistrement 78 est sélectionné, le 79 non (n° donné = N°Échéancier). Or, hormis les champs Intitulé et Objet du marché, rien d'autre ne les différencient ... ...

[Richard_35]

Bonjour GuiBar18,

Si tu supprimes ta clause WHERE, le 78 et le 79 sont-ils sélectionnés ?

[GuiBar18]

Il se passe la même chose qu'avant, le 78 est sélectionné, le 79 non.
Je trouve ça assez bizarre comme problème. En outre, j'ai deux autres requêtes qui se comportent de la même manière.

J'aiaussi vérifié, les propriétés "enregistrements uniques" et "Valers distinctes" sont bien sur NON.

[Golgotha]

Bonjour,

Moi quand je veux résoudre ce genre de problème j'applique une dichotomie sur la requête, ça marche 9 fois sur 10 :

Tu part de ta requête de base, sans clause WHERE et sans INNER JOIN.

Ensuite, tu ajoute une a une tes clauses WHERE, en regardant si entre deux tu n'as pas perdu un enregistrement.

Ensuite, tu ajoute un à un tes INNER JOIN, en regardant si entre deux tu n'as pas perdu un enregistrement.

Logiquement, tu devrais voir pourquoi et ou tu les perds.

[GuiBar18]

C'est exactement ce que je suis entrain de faire , selement ce n'est pas si simple, ces requêtes étant utilisées par pas mal de formulaires, d'états et de codes différents. Du coup, je stresse un peu et j'espère que je n'aurai pas à tout reprendre, d'où mon message un peu paniqué

Après, il y a un autre problème sur ces requêtes que je ne comprnd pas bien. Il s'agit de la propriété "Afficher tous les champs". Lorsqu'elle est sur non, la requête se déroule. Sur oui, j'ai une erreur (-3007) et il me demande 2 fois mes paramètres.
N'importe comment, la n'est pas la question, je poursuis ma démarche et je vous tien au courant.

[Richard_35]

Si tu supprimes ta clause WHERE, le 78 et le 79 sont-ils sélectionnés ?

Il se passe la même chose qu'avant, le 78 est sélectionné, le 79 non.

==> cela veut donc dire que le problème se situe au niveau des jointures : vérifies-les via l'assistant graphique, c'est plus lisible.


D'autre part, je souscris, totalement, à la méthode de Golgotha : c'était l'objet de suppression de la clause WHERE.

.../...il ne les sélectionne quand même pas (j'exécute entre 2021 et 2030 pour le coup).

==> tu te polarisais sur le WHERE, alors que le problème est ailleurs. Comme la vérité, d'ailleurs...

[GuiBar18]

Le problème est bien sur la jointure entre deux de mes tables la table "Échéancier" et la table "données financières"

Par contre je ne comprend pas tout. Que le modérateurs me pardonnent , même s'il s'agit maintenant d'une question de modélisation, je poste à la suite (pour garder un tout unifié).

Dans ma base j'ai une table principale dite "Échéancier", dont la clef est un numéro unique (le N°Echéancier). Entre autres choses, un enregistrement de cette table peut avoir (ou non) un N°Dossier. En outre, il n'y a pas unicité du N°Dossier (par exemple, N°Dossier=5012n apparait sur plusieurs enregistrements).
J'ai une autre table dite "Données financières". La clef de cette table est un numéro automatique (N°Financier).
L'idée de base était de dire qu'un N°Dossier dans l'échéancier PEUT avoir une ou plusieurs données financières. Du coup, dans ma table "Données Financières" j'ai introduit un champ N°Dossier et j'ai fait une liaison entre les deux tables concernées.

La dessus j'ai construit ma requête pour sélectionner, selon certains critères, les enregistrements de "Échéancier" tout en affichant leurs données financières. Le but est après de générer un état.

La ou la requête coince c'est que certains enregistrements sont oubliés lors de la sélection (alors que des données financières sont bien renseignées). Par contre en "supprimant la liaison" entre ces deux table dans la requête, tout se passe correctement (mais je ne vois plus les données financières qui m'intéressent).

J'en déduis qu'il faut que je change la liaison entre mes tables.

[Richard_35]

Bonjour GuiBar18,

Reprenons :

Table Échéancier :
- N°Echéancier (clé primaire)
- N°Dossier (non unique, renseigné ou nul)
...

Table Données financières :
- N°Financier (clé primaire)
- N°Dossier (?)
==> dans cette table, N°Dossier est-il unique ?

[GuiBar18]

Hélas non.
En effet, il peut y avoir plusieurs données financières par numéro de dossier. D'où l'insertion en champ clef d'un numéro automatique.
Ainsi, pour le dossier 1465 il y a les données financière 78, 79 et 81 puis 95 et 96

[Richard_35]

Mais tu as bien une table Dossier dont la clé primaire est N°Dossier, non ?

[GuiBar18]

Non.
Et j'avoue que, dans mon ignorance, je ne vois pas la finalité.

En effet, les utilisateurs renseignent directement la table échéancier (via un formulaire) et entre eux même le numéro de dossier (même si un calcul fait une suggestion)
Le seul avantage immédiat que je vois d'avoir une telle table est d'éviter les doublons sur le numéro de dossier (car il serait clef primaire d'une table).
Ou alors j'ai loupé quelque chose de très important et la table de dossier permtrait de faire la liaison correctement ?

Edit :
Une de mes citation préférée est "Aide toit et le ciel t'aidera", j'ai donc commencé la mise en place d'un table dossier, avec pour clef le Numéro de dossier. Rest à la remplir correctement et sans perdre de donnée (et garder mon outil fonctionnel, sans avoir à reprendre toutes mes requêtes et mes codes).
J'ai l'impression que je suis passé à coté de quelquechose d'essentiel ... ...

[Richard_35]

Eh bien, oui.

En plus, je suis pratiquement persuadé qu'il existe des informations propres aux dossiers (N°Dossier) qu'il serait intéressant de stocker, mais je peux me tromper et c'est toi qui connaît ton contexte.

Une même information, propre au Dossier, n'est-elle stockée à plusieurs endroits ?

[GuiBar18]

Pour préciser le contexte, les choses sont structurée comme suit :

Un eregistrment dans l'échéancier peut devenir un dossier qui peut avoir une ou plusieurs données financières.
En gros, un évènement commercial peut devenir un évènement de gestion (ouverture d'une "affaire") auquel la société apporte une réponse sous forme d'un ou plusieur devis (ou le classe sans suite).

L'échénacier stocke donc des informations relatives à l'avancement du projet (devenu un dossier, en attente de décision, etc) via un table d'avancement; des données sur la clientèle (via une table client) et des données sur l'objet du projet commercial (type, nature, intitulé etc).
Le passage au stade "Dossier" se fait uniquement par l'ouverture d'un numéro au sein de nos registre. Il n'y a pas d'informations supplémentaires (le client, l'objet et autre sont déjà renseignés)
Puis, si nous apportons une réponse financière au projet, des information de prix et d'analyse sont ajoutées.

Donc non, il n'y a pas d'information en plusieurs endroits, sauf le N°Dossier apparement.

Dans tous les cas, ton post et mon edit se sont croisés. Je met en place cette table, en essayant de ne rien perdre de ce qui existe déjà et je reprends contact (ne serait-ce que pour mettre le tag résolu)

[Richard_35]

Si j'ai bien compris, un dossier (N°Dossier) n'est créé, le cas échéant, qu'à partir d'un "projet commercial" (ou non créé). Il existe donc des projets commerciaux sans dossier, mais il n'existe pas de dossier sans projet commercial.

Est-ce bien cela ?

D'autre part, as-tu une table ProjetCommercial avec une clé primaire N°Projet (par exemple) ?

[GuiBar18]

Exactement.

Puis étape suivante, un dossier financier est créé ou non ... ... et il existe des dossier sans données financières mais pas de données financières sans dossier.

La question, est à quoi sert l'étape "Dossier" vu qu'elle ne s'accompagne de rien d'autre dans ma base de données que de l'attribution dun numéro.

En fait ce numéro est ensuite utilisé pour ouvrir un répertoire et permettre au personnes qui travaillent sur ce dossier de pointer les heures travaillées sur le dossier (création du répertoire et pointage sont distinct de ma base de données).
Par contre, comme nous sommes de simple mortels et non pas des pros de la gestion, mon chef me demande de conserver l'information d'attribution du numéro de dossier (parce que nous, sur site, en pratique c'est avec ça qu'on bosse même si ce n'est pas le cas coté gestion).

[Richard_35]

Alors pourquoi ne pas stocker le N° de projet commercial dans les tables "Echéancier" et "Données financières" ?

[GuiBar18]

Voila, la table est crée.
Effectivement, les choses vont un peu mieux du côté de ma requête et j'ai l'impression que c'est plus "propre" comme cela. En outre, cela me laisse la possibilité de faire évluer le tout.

Par contre, la requête omet toujours des éléments : ceux qui n'ont pas de données financières. A savoir qu'au départ je voulais sélectionner tous les éléments de mon critère et voir apparaitre dans le même état les données financières si elles existent (sinon une case vide).
Au jour d'aujourd'hui, les dossier n'ayant pas de données financières n'apparaissent pas.
Bon, je peux toujours contourner le problème en mettant 0 pour les données financières (et une date bidon pour les dates) mais bon ... ...

[Richard_35]

Via l'assistant, remplaces tes liens sans flèche (INNER JOIN) par des liens avec flèche à droite (LEFT JOIN). Jettes un coup d'oeil sur l'explication d'Access, elle est très claire.