Créer un formulaire servant de "requeteur"

[plousky]

Bonjour,

Je cherche a créer 1 Form qui servirait en fait de requeteur. (plusieur personnes utiliseront la base et ne connaisse pas access).

J'ai réussi à le faire avec un sous formulaire filtré selon des champs renseignés par l'utilisateur mais les champs sont donc fixés à l'avance (source basé sur requete).

L'idée serait de faire la même chose mais avec un rowsource plutôt qu'avec 1 filtre. Permettrait de définir les champs que l'on veux voir dans le sous-form en créant la source en sql.

Je ne sais pas par quel bout commencer.

Un truc du style ? :
- liste modifiable1 contenant le nom des champs d'une table : on choisit le champs que l'on veux voir (éventuellement 1 where etc..)
- ensuite, par le truchement de si modifiable1<>"" alors - liste modifiable 2.visible =true etc...

Au final on aura séléctionné tous les champs que l'on veux voir et les conditions que l'on désire.

Est ce possible comme ça ou faut il créer des tables ou requete en sql ou pire...

[Maxence HUBICHE]

Mouais ....

La vrai difficulté est de déterminé l'étendue des fonctionnalités que tu veux proposer à tes utilisateurs !
Le requêtage va se faire sur une seule table ou sur plusieurs ?
Si c'est sur une seule table, prévois-tu de permettre les synthèses ou pas ?
Et les critères, seront-ils multi-champs, ou pas ?
Et que penses-tu des ordres de tris ?

Parce que, si tu veux tout permettre, le plus simple ne serait pas de leur apprendre à faire des requêtes ?

[plousky]

Slt

Je crois effectivement que ça va être galère et long mais je travaille avec des "blondes" et j'en ai marre de devoir tout faire à chaque fois (BDD gestion de personnel utilisé au bureau)

Le plus simple peut être (vu que j'ai déjà le formulaire mais qui filtre seulement) y'a t'il moyen que l'utilisateur coche (par ex) les champs qu'il désire voir.

Sinon de manière plus général et pour mon info, je n'arrive pas à modifier la source de mon formulaire qui est basé sur une requete. Quand j'utilise qqchose comme : me.nom sous form. form.recordsource=mysql(récupéré par des champs saisis par l'utilisateur) , il me dit que la requete "xxxxxx" (xxx étant la valeurde mysql soit un SELECT .... FROM.....WHERE..) n'existe pas.

Exact mais je cherche à modifier la source de la requete qui consitue mon sous-form.

[Maxence HUBICHE]

Et tu as lu les tutoriels sur les formulaires de recherche ?

[DMboup]

Envoyé par plousky

Exact mais je cherche à modifier la source de la requete qui consitue mon sous-form.

Une zone de liste semble être plus approprier notamment pour assurer le dynamisme des colonnes choisies.

La solution que tu cherches, appliquée sur une seule table (au choix) est disponible. Mais celle intégrant plusieurs tables risques d'être plus compliquer à faire que apprendre à tes utilisateurs à construire des rêquetes comme te dit Maxence HUBICHE.

[alassanediakite]

Salut
Décris-nous un peut ta base: les tables et surtout de quoi il s'agit (gestion de quoi????)
Ensuite décris-nous les traitements (mises à jour et consultations)
En fin bref, je ne comprends pas bien ton problème.

[Philippe JOCHMANS]

Bonjour

Juste une réflexion personnelle.

Je ne vois pas à quoi cela peut servir si les gens ne connaissent pas Access.
S'il prennent n'importe quel champ, les résultats seront loin d'être probants.

Comme le dit Maxence dans le deuxième post, il faut mieux apprendre aux gens à faire des requêtes et à comprendre Access.

Le mieux c'est les formulaires de recherches multicritéres, va voir les tutos.

Starec

[DMboup]

Envoyé par Starec

Juste une réflexion personnelle.
Je ne vois pas à quoi cela peut servir si les gens ne connaissent pas Access.

Moi si. Un exemple. Dans une boutique par exemple
1. Certains utilisateur voudrons avoir seulement la liste des produits
2. D'autres la liste des produits et leur prix de vente
3. D'autres encore la liste des produits dont la quantité en stock et égal à une valeur
4. Enfin d'autre la liste des n produits les plus prix cher.

Les utilisateurs n'ont pas besoin de connaitre Access pour avoir ces besoins. Et le développeur est obligé (peut être pas toujours) de faire autant de requête solitaire pour répondre au besoin. Dans mon exemple c'est une seule table, mais rien n'empeche d'avoir le même besoin pour les clients, les commandes, les factures en instance de réglement.

Envoyé par Starec

S'il prennent n'importe quel champ, les résultats seront loin d'être probants.

La n'est pas le problème. Il est tout à fait possible de définir les tables et les champs à voir sur la solution à mettre en place.

Les problèmes sérieux sont bien résumé par Maxence HUBICHE