Discussion :

[sabotage]

Bonjour,

Je me tourne encore une fois vers vous, n'arrivant pas à trouver la solution à mon problème.

Voici le cas simplifié :

J'ai une table STOCK qui liste l'état de colis
Index - Colis - Ville - id_Transfert

et une table TRANSFERT qui liste des trajets possibles
Index - Ville_départ - Ville_arrivée

Un formulaire présente le contenu de la table STOCK (sa source est la table STOCK).

Le controle pour n_Transfert est une liste déroulante et je veux que les valeurs possibles se limitent aux elements de la table TRANSFERT pour lesquels la ville de départ est la ville de stock.

J'ecris donc

Code :

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

SELECT Index FROM Transfert WHERE Ville_départ = Stock.Ville;

Malheureusement, il propose pour tous les enregistrement, la liste correspondant à la ville du premier enregistrement.

Je suppose que je fais une grossiere erreur sur la facon d'utiliser la valeur d'un champ de l'enregistrement courant.

Pourriez-vous m'aider ?
Merci


PS : Je précise juste que si j'indique une valeur numérique à la place de Stock.ville dans ma clause WHERE, j'obtiens bien la liste correspondant à cette valeur numérique.

[Magnus]

Etonnant que tu n'aies pas de message d'erreur avec cette requête (si toutefois tu n'as pas commis d'erreur en écrivant ton message ?) : tu utilises un attribut de la table STOCK dans la clause WHERE alors qu'elle ne figure pas dans la liste des tables utilisées dans la clause FROM.

Est-ce que cette requête corrige ce problème :

Code :

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

1
2
3
SELECT Index
FROM TRANSFERT
INNER JOIN STOCK ON (Ville_depart = Ville)

Remarques :
1°/ la syntaxe de la clause INNER JOIN peut être légèrement différente selon ton SGBD
2°/ je te CONSEILLE FORTEMENT d'enlever tous les accents et autre caractères non diacritiques de la structure de ta base (accents, cédilles, etc.)

[Médiat]

sabotage>> Si tu travailes avec FORM de ORACLE, et que Stock.Ville représente le contenu d'un bloc de données nommé Stock, il faut sans doute écrire

Code :

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

WHERE Ville_départ = :Stock.Ville

.

Magnus >> Ce sont les signes diacritiques qu'il faut bannir

[Magnus]

Autant pour moi, j'ai beau me relire, des fois je suis un vrai

[sabotage]

Bonne journée à tous,

Il est effectivement plus raisonnable que les tables des colonnes utilisées soient indiqués dans le FROM

Par contre, la requete

Code :

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

1
2
3
SELECT Index 
FROM TRANSFERT 
INNER JOIN STOCK ON (Ville_depart = Ville)

affiche tous les enregistrements communs à la table STOCK et à la table TRANSFERT.

Je souhaiterais avoir uniquement les enregistrements de TRANSFERT pour lesquels Transfert.Ville_depart = (Stock.Ville_de_l'enregistrement_sur_lequel_je_suis_dans_le_formulaire)

---

Je ferrais plus attention avec les caractères non diacritiques
J'ai deja lu les conseils sur le site pour le choix des noms ; auriez-vous d'autres documents à me conseiller sur la facon de nommer les colonnes etc. (ex : nommer id_xxxx une colonne qui fait reference à un index xxxx)


Merci

[Magnus]

Je souhaiterais avoir uniquement les enregistrements de TRANSFERT pour lesquels Transfert.Ville_depart = (Stock.Ville_de_l'enregistrement_sur_lequel_je_suis_dans_le_formulaire)

Code :

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

1
2
...
WHERE STOCK.Ville = :VilleDuForm

où :VilleDuForm permet de paramétrer ta requête ; c'est-à-dire qu'à l'exécution de cette requête il va falloir que tu saisisses une valeur pour VilleDuForm
Tu peux aussi créer ta requête dynamiquement en concaténant à ta requête la valeur à utiliser dans la clause WHERE (ie VilleDuForm)

auriez-vous d'autres documents à me conseiller sur la facon de nommer les colonnes etc. (ex : nommer id_xxxx une colonne qui fait reference à un index xxxx)

Ce document devrait t'en dire plus

[sabotage]

J'etais parti sur un programme de SQL, ca dérive plus sur un probleme Access en fait.
Maintenant que mon écriture SQL est "propre" je vais juste avoir à travailler sur la bonne facon de l'écrire dans Access.

Merci pous vos réponses et pour les conseils.