Recherche dans deux tables differentes [Résolu]

[Shades]

Bonjour,

J'ai un code pour faire une recherche dans une table, mais je souhaiterais qu'il me fasse la recherche dans deux tables, TbProduits40089 et TbProduitsSFRP5, comment dois-je faire ?

Code :

1
2
 
In (SELECT TbProduits40089.ID FROM TbProduits40089 WHERE (((TbProduits40089.Designation) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreDesignation] & "*") AND ((TbProduits40089.Article) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreArticle] & "*"));)

On m'a déjà aiguillé pour que la liste déroulante de filtrage affichant la désignation et une autre pour les Articles mais je ne vois pas comment intégrer cela dans le code de recherche tiré d'une appli de "Claude Leloup"


D'avance merci
cordialement

[nolliug]

Bonjour Shades

Voici ce que je ferai :

1- creer une requete selection comprenant tes 2 tables
2 - etablir une relation entre les champs identiques de chaque tables (designation et article)
3 - selectionner les champ dant ta requete que tu souhaites obtenir.

a+
Vincent

[Shades]

Bonjour Nolliug,

Tous cela je l'ai déjà fait pour la liste déroulante, cette fonction est pour le filtrage et je ne sais pas comment intégrer les deux tables dans ce code. Code de notre ami Claude Leloup pris dans une appli qu'il a mis en place pour de la gestion de stock.

Mais merci tout de même
cordialement

[ClaudeLELOUP]

Bonjour à vous deux,

tu copies ton code actuel dans un traitement de texte ;
tu changes TbProduits40089 enTbProduitsSFRP5 ;
tu as maintenant deux ensembles ;
tu exprimes que la valeur doit être comprise dans l'un OU dans l'autre ensemble.
Ton code devient :

Code :

In (SELECT TbProduits40089.ID FROM TbProduits40089 WHERE (((TbProduits40089.Designation) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreDesignation] & "*") AND ((TbProduits40089.Article) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreArticle] & "*"));) or In (SELECT TbProduitsSFRP5.ID FROM TbProduitsSFRP5 WHERE (((TbProduitsSFRP5.Designation) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreDesignation] & "*") AND ((TbProduitsSFRP5.Article) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreArticle] & "*"));)

[Shades]

Cher Claude,

Merci d'être encore là pour ma formation Access
Si j'ai bien compris en fait il suffit d'ajouter "ou dans/OR IN" et autant de fois que de tables non ?

Et concernant la requête dois-je ajouter la/les table(s) concernées ?

voir image

Merci encore
Cordialement, bien à toi
Sylvain

[ClaudeLELOUP]

Si j'ai bien compris en fait il suffit d'ajouter "ou dans/OR IN" et autant de fois que de tables non ?

En fait chaque clause in() représente un ensemble de valeurs possibles. En les liant avec "OR", tu exprimes que toutes les valeurs comprises dans l'union sont valables.

Et concernant la requête dois-je ajouter la/les table(s) concernées ?

Non, ça n'a rien à voir !

Ta requête va d'abord sélectionner toutes les valeurs et ensuite ne retenir que celles exprimées dans la condition.

Fais le test avec des tables réduites pour comprendre ce qui se passe.

[Shades]

Claude,

Dans mes 2 listes déroulantes j'ai :

Code :

1
2
 
(SELECT TbProduits40089.Designation FROM TbProduits40089) UNION (SELECT TbProduitsSFRP5.Designation FROM TbProduitsSFRP5);

et

Code :

1
2
 
(SELECT TbProduits40089.Article FROM TbProduits40089) UNION (SELECT TbProduitsSFRP5.Article FROM TbProduitsSFRP5);

Tout va bien mes produits y apparaissent, mais le formulaire ne me charge pas les deux tables produits, la TbProduitsSFRP5 ne s'affiche pas, le code je le rajoute bien là où tu avais mis le tiens sur la base de gestion, en fait je reprend ton formulaire liste de produits de la gestion de stock et je l'adapte pour cet appli, donc il ne devrait pas y avoir d'erreur alors où est-ce que je me plante Claude ?

Bien à toi,
Sylvain

[ClaudeLELOUP]

Sylvain, je ne comprends pas la question.

Pour plus de clarté, si ton souci concerne cette discussion au sujet de la gestion des stocks, je te suggère de clore cette discussion-ci et de poursuivre dans la précédente en précisant le contexte (tel formulaire, telles tables…).

Ce sera, je crois, plus simple pour tout le monde.

À tout à l'heure, là-bas.

[Shades]

Claude,

Non non du tout, la gestion de stock reste plus que moi avec le guide d'utilisation pour finaliser; tout roule sinon ...

C'est une autre appli que l'on m'a demandé de faire, et dans cette appli j'ai deux tables,

Une table produit "TbProduits40089" correspondant à des tarifs non forfaitisés et une table "TbProduitsSFRP5" correspondant à des tarifs forfaitisés.

Je crée un formulaire pour afficher tous ces produits avec un filtre se basant sur la désignation et les articles.

Et pour faire cela je me base sur ce qui a été fait dans la gestion de stock et sur les conseils et formations que tu m'a donné, ceci est bien un autre sujet Claude, désolé si je n'ai pas été clair


Bien à toi
Sylvain

[f-leb]

bonjour à tous,

question comme ça ...

les deux tables ont rigoureusement les mêmes champs. Ne serait-il pas plus simple de fusionner les données dans une seule table avec un champ supplémentaire ='40089' ou 'SFRP5' pour distinguer les deux types de produits ?

[Shades]

Ou alors créer une table TbProduits qui regrouperait les deux non ?
C'est ce que j'ai fait et cela à l'air de fonctionner, j'ai créer une requête de fusion RProduits, et remplacé TbProduits40089 par RProduits ce qui donne :

Code :

1
2
 
In (SELECT RProduits.Designation FROM RProduits WHERE (((RProduits.Designation) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreDesignation] & "*") AND ((RProduits.Article) Like "*" & [Formulaires]![FmBaseProduits]![zdlFiltreArticle] & "*"));)

La question est, de cette façon, cela alourdit il la base ?

Cordialement

[f-leb]

Envoyé par Shades

... j'ai créé une requête de fusion RProduits, et remplacé TbProduits40089 par RProduits ...

oui, pourquoi pas.

La question est maintenant de savoir pourquoi séparer les données de même nature dans deux tables différentes si la majorité des traitements consiste à les re-fusionner avec une requête. Une contrainte particulière ? (TbProduits40089 et TbProduitsSFRP5 seraient raccordées à d’autres tables mais par forcément les mêmes selon le type de produit ? Des traitements séparés particuliers ? )

A noter également que les données d’un formulaire dont la source est une requête UNION n’est pas modifiable. C’est assez embêtant parfois.

[Shades]

Bonjour f-leb,

Quand tu dis que ce n'est pas modifiable, tu veux dire que si je rajoute des produits ils n'apparaitrons pas dans la table UNION ?

La question est maintenant de savoir pourquoi séparer les données de même nature dans deux tables différentes si la majorité des traitements consiste à les re-fusionner avec une requête. Une contrainte particulière ? (TbProduits40089 et TbProduitsSFRP5 seraient raccordées à d’autres tables mais par forcément les mêmes selon le type de produit ? Des traitements séparés particuliers ? )

La contrainte est que ces deux tables produits se basent sur deux choses, l'une des tables est une série de prix forfaitisée l'autre à un coef multiplicateur, je dois de plus jongler avec des dates de contrat sans pour autant modifier les attachements qui seraient déjà fait.

Donc je suis partis du principe de tout séparer, comme je suis débutant je suis tout ouïe sur les suggestions pratiques, Claude (Merci encore à toi Claude) m'a déjà bcp aidé sur une autre appli ce qui m'a mis le pied à l’étrier sur Access mais il me reste bien des choses à apprendre

Prochainement je dois m’atteler à la génération des attachements à proprement dit si une âme volontaire veux bien me guider je suis prenneur

Merci d'avance,

Cordialement
Sylvain

[f-leb]

bonsoir Shades,

Envoyé par Shades

... tu veux dire que si je rajoute des produits ils n'apparaitrons pas dans la table UNION ?

Tu ne peux pas ajouter d’enregistrements dans une requête UNION, car Access ne peut tout simplement pas deviner si l’enregistrement doit être ajouté à TbProduits40089 ou bien à TbProduitsSFRP5.

En l’état actuel, je suggère quand même de fusionner le tout dans une unique table TbProduit :
TbProduit(idProduit, Designation, …, prix, TypeProduit)

TypeProduit pouvant prendre les valeurs "40089" ou "SFRP5" par exemple pour distinguer les deux types. Le type de produit étant identifié, tu peux filtrer ou appliquer des règles de calcul différentes dans les requêtes.

Sinon, ces "attachements" semblent être un autre problème qui mériterait une nouvelle discussion, en expliquant ce que peut bien recouvrir ce terme dans ton contexte.

[Shades]

Bonjour f-leb,

Oki Je vais refaire toutes les tables une à une, aurais tu le temps de me guider pas à pas sur ce sujet, car je vois qu'il me reste bien des choses à apprendre.

Premier pas refaire les tables et leur relations ?

Cordialement,
Sylvain

[Shades]

f-leb,

Voici ce que j'ai fait déjà, peux tu me dire si cela est mieux ainsi.
J'ai refait les tables et les relations, j'ai un doute sur ces dernières, sont elles ok à ton avis ?

Cordialement
sylvain

[Shades]

Bonsoir à vous qui me suiviez

J'ai mis le zip dans un autre sujet ouvert

demande d'aide pour une appli en pas à pas.

Merci
Cordialement

sylvain