Discussion :

[lmollard]

Bonsoir @ tous,

Voilà quelques jours déjà que je me creuse la tête, que je fais des tests croisés, et que je n'y comprends toujours rien... je viens donc en faire appel à vos bonnes idées...

Voilà l'histoire, je fais simple (avec une base test), sinon ce serait trop compliqué à expliquer :

Dans une table (nommée A) j'ai (entre autres) 2 champs (nommés B et C). Ces champs contiennent des nombres. Ces nombres seront majorés ou minorés (selon le cas) au moment de faire la requête par des nombres saisis dans des contrôles dans un formulaire (pour mon essai, j'ai remplacé celà par du +2). Je cherche à faire une requête qui va me montrer les enregistrements qui correspondent à un critère que va saisir l'utilisateur dans un formulaire (nommé Formulaire1). L'utilisateur va saisir un nombre, et je souhaite que ce nombre (on va le nommer Texte0, comme le nom du contrôle de Formulaire1) soit compris entre ceux des champs B et C. pour faire simple : B<Texte0>C ou C<Texte0>B.

Donc, je fais ma requête comme suit :

Code :

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

1
2
3
4
 
SELECT A.N°, A.Désignation, [B]+2 AS B2, [c]+2 AS C2
FROM A
WHERE ((([B]+2)>=[Formulaires]![Formulaire1]![Texte0]) AND (([c]+2)<=[Formulaires]![Formulaire1]![Texte0])) OR ((([B]+2)<=[Formulaires]![Formulaire1]![Texte0]) AND (([c]+2)>=[Formulaires]![Formulaire1]![Texte0]));

Et là, j'obtiens des réponses complètement farfelues ! Parfois c'est bon, parfois je n'ai aucun résultat (alors qu'il devrait y en avoir) et parfois j'ai trop de résultats (s'y trouvent des enregistrements qui ne devraient pas y être)

Dans mes tests, tout refonctionne impeccable lorsque :
- je ne fais plus appel au champ calculé (que je prends B et C sans calcul),
- ou bien que je remplace la référence au contrôle Texte0 par un nombre au hasard,
- ou bien lorsque je supprime les signes < et >

Quelqu'un a t'il une idée de comment résoudre ce problème ?

Par avance, merci pour vos réponses...

Bonne soirée,

Lionel

[loufab]

Bonjour,

Le problème est que tu majores tes données et que tu fais une condition d'extraction (where) sur le résultat également majoré. Un peu capillotracté comme méthode.

Pourquoi ne pas faire simple. Tu extrais des données non-majorées à partir d'une condition majorée.

Il y a un opérateur pour le bornage Between. Il donne de meilleur résultat que les < et >.

Place également tes liens en paramètres.

Cordialement,

[lmollard]

Salut et merci pour ta réponse...

C'est en fait un peu plus compliqué que ce que j'ai expliqué, j'ai fait simple en présentant une base test qui a les mêmes symptômes !

En réalité, voici ce que je cherche à faire :

C'est une base de données de coins photos pour de la photo de trains.

Le nombre à majorer ou minorer est l'axe de la voie (en degrés). Celui-ci est saisi dans le formulaire "coins photos". A coté de ce nombre, il y a un bouton à bascule qui indique si le photographe est à droite (valeur 1) ou à gauche (valeur 2) du train.
Puis j'ai un formulaire de recherche de coins (avec déjà pleins d'autres critères de recherche) dans lequel on saisit l'azimut du soleil à un instant T (qui correspond à l'horaire de passage d'un train), ainsi que le décalage en degrés pendant lequel la photo est possible avec un bon ensoleillement (ces valeurs sont des valeurs par défaut, qui doivent être modifiables : 20° (en dessous, le flanc du train serait mal éclairé) et 80° (au dessus, le nez du train serait mal éclairé)).
Par exemple : dans un coin donné, l'axe de la voie est à 180° (direction plein sud) et le photographe se trouve à droite du train (valeur 1, du bouton à bascule). La plage optimale de l'azimut du soleil pour la photo dans ce coin va être de 200° (180+20°) à 260° (180+80°). les 20 et 80 sont les valeurs de la plage de bon ensoleillement (susceptibles d'être modifiées lors d'une recherche, si besoin).
Le fait d'additionner est dû au fait d'être à droite du train. Si on avait été à gauche du train, il aurait fallu soustraire (180-20=160° et 180-80=100°). Donc, dans ma fameuse requête de recherche de coin, mes champs calculés ont un vraifaux() avec : si train à droite 1=ajouter, et sinon soustraire... Et c'est le résultat de ces 2 champs que je veux évaluer.

J'espère que ces explications restent malgré tout claires !!! s'il faut des compléments d'explication, je les fournirait avec plaisir !

Merci pour ton aide...

Lionel

[loufab]

En effet vu sous cet angle !

Essaye une requete intermédiaire.

Dans un premier temps fait la majoration, puis utilise cette requete comme source pour l'extraction.

c'est pas top mais ça peut régler ce problème.

Cordialement,

[lmollard]

En fait, j'utilise déjà une requête intermédiaire...

Pour faire plus simple, je joins à ce post un extrait de ma base de données (copie des tables, formulaires et requêtes de l'originale)

Pour tester la loufoquerie de la chose, rendez-vous dans le formulaire "recherche coin", puis taper dans "azimut du soleil" :
- 100 : 0 réponses, alors qu'il devrait y en avoir 4
- 150 : 2 réponses, alors qu'il devrait y en avoir 1
- 200 : 5 réponses, alors qu'il devrait y en avoir 2

etc... et même parfois, les réponses diffèrent d'une fois sur l'autre...

La requête qui contient les azimuts après calcul est "Recherche Coin Pré-requete". pour plus de lisibilité dans les tests, le champ désignation est formé comme suit :
100 : azimut qui doit correspondre à la recherche
PG ou GP : Petit nombre et Grand nombre, ou Grand nombre et Petit nombre.

A toutes fins utiles, je suis sous Access 2003 SP3.

Merci pour ton aide...

Lionel