Discussion :

[Lilou51]

Bonjour à tous,

Je suis enquiquinée et je sollicite votre aide...
J'ai une requête super longue et souhaite l'alléger en faisant des sous-requêtes (plutôt que faire des conditions "si").
Je bosse sur des données comptables.

Pour faire court, j'ai identifié, dans une requête qNatureErreur, les éléments qui me posait problème :

Code :

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

1
2
3
4
SELECT Ecritures.NumUniq AS NumUniq, "Erreur" AS Erreur
FROM Ecritures
WHERE (([Ecritures].[Centre]=Left([Ecritures].[nature],Len([Ecritures].[Centre])))=0) 
ORDER BY Ecritures.NumUniq;

J'obtiens une short list de mes écritures en erreur.

Maintenant, je voudrais prendre ma liste entière d'écriture et renseigner "Erreur" pour tous les "NumUniq" de la requête qNatureErreur et Null pour les autres.

En tout logique, j'ai fait une nouvelle requête comme suit :

Code :

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

1
2
SELECT Ecritures.NumUniq, qNatureErreur.Erreur
FROM Ecritures LEFT JOIN qNatureErreur ON Ecritures.NumUniq = qNatureErreur.NumUniq;

Mais j'obtiens " le NumUniq + erreur " partout, indépendamment de ma sous-requête qui aurait dû limiter la mention "Erreur" à quelques éléments.

La problématique est + complexe que ça, mais je pense que si l'on dénoue cela, je pourrais déployer sur le reste.

Qu'est-ce que j'ai loupé ?

Merci de votre aide

[marot_r]

Bonjour.

Ton critère de sélection (([Ecritures].[Centre]=Left([Ecritures].[nature],Len([Ecritures].[Centre])))=0) est bizarre.
Je me perds dans les parenthèses, tu testes quoi exactement (met un exemple des valeurs).
Ce qui me paraît faux est le =0 à la fin.

As-tu validé que qNatureErreur retourne bien seulement les écritures que tu voulais et pas toutes tes écritures ?

A+

[Lilou51]

Bonjour,

Merci de t'être penché sur mon pbl.

J'analyse l'activité d'un hôtel resto.
Dans le centre, j'ai usuellement un code en 3 lettres.
Je vais avoir dans centre des trucs du genres "2zz" (hébergement), ou "3zz"(resto), ou boutique, spa....

Quand on veut préciser le type de repas, on remplit la Nature, qui normalement est une extension du centre Restaurant (3zz).
Par exemple, le centre 3zz aura comme nature 3zz001 (petit dej), 3zz002 (dej), 3zz003 (diner)... snack, pic nic...

Donc je teste que les 3 premiers caractères de la nature soient identiques aux 3 caractères de centres.
Sinon, ça ne veut rien dire (ex : centre boutique, nature diner !!?? ).
Donc, si ce n'est pas ok (si test = 0), je retourne les éléments qui ne vont pas. Ainsi, je souhaite avoir plusieurs type de réponse :
=> Centre (si je n'ai pas de nature)
=> ou Nature (si j'ai les 2 et qu'ils sont compatibles),
=> ou, ds ce bout de requête, je retourne "Erreur", afin que le comptable corrige sa bêtise.

La requête retourne le NumUniq d'1 seul élément seulement, celui qui est en erreur.

En revanche, quand je mets l'ensemble des NumUniq, et que je le lis à ma requête d'erreur, il me renseigne "Erreur" partout....
Curieux isn't it ?

Merci de ton aide.
Nota: pour les parenthèse, c'est Access qui les a mises... si ( (centre = premiers caractères de nature) = faux )... tu me diras, j'aurais pu écrire (centre <> premiers caractères de nature)

[tee_grandbois]

bonsoir,
il faudrait un jeu d'essais pour détecter le problème, car la syntaxe semble correcte.
Sinon pourquoi ne pas le faire en une seule requête en utilisant Vraifaux (IIf) pour tester l'erreur

Code :

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

1
2
3
SELECT NumUniq, [Centre], [nature], iif([Centre]=Left([nature],Len([Centre])),Null,"Erreur") AS Erreur
FROM Ecritures
ORDER BY NumUniq;

[Lilou51]

Bon, je n'ai toujours pas l'explication du renvoi d'info de type texte sur toutes les lignes quand une table A est liée à cette même table A filtrée (sous-requête) au lieu de simplement renseigner cette info texte sur les lignes uniquement concernées par la sous-requête. Et cela continuera à être un mystère, pour moi, pour le moment...

Mais, mon but initial était de passer de 29 min de temps d'exécution à beaucoup moins et ce but a été atteint (la requête complète était bcp + longue que le bout de code présenté)... après un long stade à 7min, je suis à présent en instantané ! Nettement mieux !!! (surtout quand on sait que la requête doit être effectuée sur 10 sociétés !).
Je pensais que mes conditions vraifaux prenaient du temps de calcul (et voulais passer par des sous-requêtes pour limiter le nb de lignes de calcul), mais c'était surtout un argument "not in select..." qui pesait très lourd ds le timing.

J'ai donc cassé toute ma requête, changé de manière de penser, et me suis rendue compte que mes vraifaux pouvaient perdurer... dès lors que je n'avais plus "not in" ds ma requête.

Mon pbl de timing est donc résolu.
Quant à l'explication initialement recherchée... et bien tant pis ! (si qqun sait la solution, je reste à l'écoute ... mais juste pour savoir !!)

Merci de votre aide. A défaut de solution au pbl présenté, ça m'a aidé à remettre les choses en perspective !