séquence des événements ACCÈS

Question

quelle est la bonne façon de faire ce qui suit:

1. obtenir DATE comme entrée utilisateur
2. exécution d'une requête
3. générer un rapport qui utilise la requête

c'est la solution que je pensais:

1. ont une forme qui prend l'entrée d'utilisateur
2. exécuter la requête
3. ouvrir le rapport

quelle est la bonne façon de le faire>?

Answer 1

Je ne suis pas d'accord avec cette approche, car je n'aime pas lier les rapports à des formes particulières. Au lieu de cela, j'utilise un formulaire de dialogue (comme ici) qui est ouvert dans l'événement OnOpen du rapport, et écrit la source d'enregistrements du rapport. Si vous voulez que le rapport puisse être exécuté sans ouvrir la boîte de dialogue, vous pouvez le rendre conditionnel à OpenArgs ou, disons, si la propriété Filter est déjà définie (ce qui arrive si vous utilisez DoCmd.OpenReport avec un Argument WHERE). Je souhaite que les rapports et les boîtes de dialogue soient aussi indépendants que possible, et souvent j'utilise un module de classe autonome comme structure de stockage de données, et je le vérifie dans l'événement OnOpen. Si la variable publique de l'instance correspondante du module de classe est Nothing, exécutez simplement le rapport, sinon, extrayez les données des propriétés de l'instance de module de classe et écrivez la source d'enregistrements.

De cette façon, vous pouvez avoir le formulaire de dialogue et le rapport complètement indépendants. Les deux ne doivent rien savoir l'un de l'autre, mais les deux seront utilisés avec le module de classe (bien que le formulaire n'ait pas besoin de savoir quoi que ce soit à propos de l'instance de module de classe).

Pour plus de détails, il suffit de demander.

Ceci est un sujet compliqué, et j'ai passé des années à le travailler pour rendre les applications aussi maintenables que possible. Découpler les objets UI les uns des autres est l'une des choses qui permet une meilleure réutilisabilité, et, par conséquent, une meilleure maintenabilité et extensibilité. (Bien sûr, vous n'avez pas besoin d'utiliser des modules de classe - vous pouvez utiliser des types définis par l'utilisateur, ou des tableaux ou autres, mais j'aime la possibilité d'avoir plusieurs instances de la même structure, ce qui est l'ensemble point d'un module de classe)

Answer 2

Je créer un bouton sur le formulaire dans lequel vous générez la requête et ouvrez le rapport en mode aperçu (en supposant qu'ils ne veulent pas simplement l'envoyer automatiquement à l'imprimante par défaut) dans la procédure événementielle Click pour le bouton .

Answer 3

Une requête peut faire référence à un formulaire archivé en tant que paramètre d'entrée, qui peut être utilisé comme requête pour les résultats du rapport.

• Donc, avoir une forme avec un utilisateur date d'entrée.
• Placez un bouton qui ouvrirait le rapport .
• le rapport doit utiliser une requête/Embedded SQL , qui utilise le champ du formulaire en entrée.

Généralement, le rapport, lorsqu'il est exécuté sans le formulaire ouvert, demande la valeur du "champ de formulaire". Par conséquent, en général, vous devez créer un formulaire Rapports, à partir duquel vous pouvez générer des rapports, avec les champs requis pour les rapports.