Discussion :

[VIRGINIE87]

je souhaiter obtenir un conseil pour savoir s'il est possible de simplifier mes 5 requetes en une seule

[francishop]

Bonjour,

Comment attaquer pour te répondre.. Le sujet est vaste. Je fais partie de ceux qui ont attendu qu'un autre intervienne pour dégrossir le problème. Vu le manque de volontaires….

Le souci principal qu'on va rencontrer si l'on veut simplifier ces 5 requêtes en une seule provient du manque de relations entre les tables.
Exemple : TDateTriage-->[ N°Date]--> Clef primaire -->NuméroAuto = Parfait. Nous avons de quoi nous référer à un enregistrement unique. Puis dans cette table un champ texte [DateTriage]
Mais dans la table TTriage –-> [DateTriage] est un champ texte isolé; Nous perdons la qualité de champs unique.
C'est pourquoi il faut prévoir la création de liste déroulantes qui apporteront à l'utilisateur un confort de saisie et d'être en fait notre champ numérique.

Nous retrouvons ce même souci avec TFournisseur --> TListeArticle --> mais qui là est saisi sous forme numérique ce qui est bien mais laisse l'initiative à l'utilisateur et n'est pas très fiable. Alors pourquoi pas une liste de choix basée sur TFournisseur?

De plus nous retrouvons ce que nous voulons éviter : une erreur de saisie dans la table TDateTriage-->[ DateTriage]= MAI 206. Ce qui nous donnera quelques erreurs ultérieurement sur Mai 2006. Alors qu'en se référant à [N°Date] qui est sans doublons--> Pas de soucis. (Même erreur avec OCTOBER 2006 et Août 2007?=Les Vacances!)

Et ainsi de suite. C'est pourquoi, avant d'envisager les requêtes qui dans ce cas seront adaptées au but recherché, il convient de revoir les relations.

J'oubliais la question principale. Dans l'état actuel on peut simplifier sans retoucher a tes requêtes genre :

Code SQL :

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

1
2
3
4
5
6
SELECT TDateTriage.N°Date, TTriage.DateTriage, Sum([QteChoixA]+[QteChoixD]
+[Qte2eme]+[QteRetouche]+[QteRebut]+[QteCasse]) AS QteTriee, Sum([QteChoixA]+[QteChoixD]) 
AS QteDecorable, TFournisseur.N°Fournisseur
FROM TFournisseur, TTriage INNER JOIN TDateTriage ON TTriage.DateTriage=TDateTriage.DateTriage
GROUP BY TDateTriage.N°Date, TTriage.DateTriage, TFournisseur.N°Fournisseur
HAVING (((TFournisseur.N°Fournisseur) Like [?]));

Cordialement.

[mout1234]

Bonjour,


francishop a raison, il ne s'agit dans un premier temps d'améliorer tes requêtes mais de corriger les anomalies de conception.

Concernant 4 de tes requêtes, elles font appel à la table TFournisseurs sans relier celle-ci aux autres tables. Sauf cas très particuliers, il faut que tu établisses un lien avec les autres tables de ta requête. Sans lien, tu vas obtenir toutes les combinaisons possibles entre les tables (encore appelé une multiplication). Dans ton cas, cela ne fait qu'ajouter une colonne avec le code fornisseur sélectionné.

Il te faut donc dans un premier temps revoir ton modèle de données qui présente de multiples anomalies. Suite à quoi, tes requêtes devraient être plus évidentes à mettre en place.
Je t'invite à consulter les trés bons tutos de Maxence, qui te donneront de bons repères:
http://mhubiche.developpez.com/Access/cours/bases/
http://mhubiche.developpez.com/Access/tutoJointures/


Bon courage

[mout1234]

Dans l'état actuel on peut simplifier sans retoucher a tes requêtes genre...

En fait, vu l'absence de relation avec la table TFournisseurs et le critère associé au numéro, la table TFournisseur ne sert à rien...

Quelque chose de ce genre donnera la même chose

Code SQL :

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

1
2
3
SELECT .... [Quel code affciher] as NumFournisseur 
FROM TTriage INNER JOIN TDateTriage ON TTriage.DateTriage=TDateTriage.DateTriage
GROUP BY TDateTriage.N°Date, TTriage.DateTriage

On est bien d'accord que cela ne correspond pas au résultat attendu . Il faut donc repasser par la case tables et relations.

[VIRGINIE87]

juste une petite précision qui je pense ne faciletera pasreelement les choses est que la saisie des resultats de triage existe deja par le biais d'une feuille excel.cette feuille est idem tous les mois (a voir dans un autre post si on peut transfere les valeurs de excel dans la table TTriage)


Voici une mise a jour du fichier a partir des précedentes remarques
j'ai remplacé dans la table TTriage –-> [DateTriage] par [N°Date]

(Même erreur avec OCTOBER 2006 et Août 2007?=Les Vacances!)

OCTOBER 2006 a ete modifie en OCTOBRE 2006
Août 2007 correspond bien aux Vacances
mais je possede un soucis au niveau de la relation en [N°Date] de TDetailDate et [N°Date] de TTriage

[francishop]

Bonjour,

Pourquoi ces doublons dans la désignation Article?

Designation Article N°Article
Couv sucrier.........................260
Couv Sucrier........................243
CP creuse PM 115 Céladon......347
CP creuse PM 115 Céladon......213
CP creuse PM 115 Rose..........348
CP creuse PM 115 Rose..........215
CP creuse PM 115 Vanille........349
CP creuse PM 115 Vanille........216

Une requête pour trouver les doublons :

Code :

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

1
2
3
4
5
SELECT TArticle.DesignationArticle, TArticle.N°Article
FROM TArticle
WHERE (((TArticle.DesignationArticle) In (SELECT [DesignationArticle] 
FROM [TArticle] As Tmp GROUP BY [DesignationArticle] HAVING Count(*)>1 )))
ORDER BY TArticle.DesignationArticle;

Tu as deux numéros de triage concernant les dates qui sont à revoir; Ce qui t'empêches d'appliquer l'intégrité référentielle. Pour vérifier ceci une requête de non correspondance fait l'affaire.

Code :

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

1
2
3
SELECT TTriage.N°Triage, TTriage.N°Date, TTriage.N°Article
FROM TTriage LEFT JOIN TDateTriage ON TTriage.N°Date = TDateTriage.N°Date
WHERE (((TDateTriage.N°Date) Is Null));

On a encore un problème de saisi : MAI 206
Il faut absolument créer des listes déroulantes qui pallient à ce genre d'erreurs puisque la référence est le N° et non la saisie de l'utilisateur.

Concernant les vacances Août 2007. Les vacances n'existaient pas en AOUT 2006 et AOUT 2005?
Il faut prendre l'habitude de dissocier l'utilisateur du concepteur. L'utilisateur sait qu'il va partir en Août 2007. Mais le concepteur doit prévoir si un remplaçant intervient. Il est très difficile de le faire lorsqu'on a les deux "casquettes". Mais prenons dés le départ de bonnes habitudes.

En fait, vu l'absence de relation avec la table TFournisseurs et le critère associé au numéro, la table TFournisseur ne sert à rien...

Tout à fait juste..Je me demandes si je n'ai pas fait une erreur en te dirigeant vers une voie palliative temporaire consistant à interroger tes requêtes telles que.

Cordialement.

[francishop]

Re Bonjour,

J'y reviens. J'avais pas fini...

Que veut dire dans tes requêtes : "TTriage.DateTriage"
Alors que tu as DateTriage dans la table TDateTriage
Et N°Date dans la table TTriage

39.1 Mo pour ta base ça fait peut-être un peu beaucoup. Après compactage on obtient 895 Ko. Ce qui est beaucoup mieux. Il faut lier dans tes requêtes les tables, même en l'état, c'est-à-dire sans intégrité référentielle. TDateTriage.[N°Date] -->TTriage.[N°Date]

Cordialement.

[VIRGINIE87]

Concernant les 5 requetes je n'avais pas réalisées les modifs nécessaires, vu les modifs que tu m'as fait faire auparavant la modif au niveau de la requete est donc logique

mout1234 a écrit :
En fait, vu l'absence de relation avec la table TFournisseurs et le critère associé au numéro, la table TFournisseur ne sert à rien...

Tout à fait juste..Je me demandes si je n'ai pas fait une erreur en te dirigeant vers une voie palliative temporaire consistant à interroger tes requêtes telles que.

comment dois je proceder, il faut tout de meme que je conserve la table TFournisseurs