Source de formulaire ou d’état

Je fais reposer mes formulaires sur des tables, ce qui facilite la saisie et la consultation des données. Y a-t-il un intérêt à utiliser une requête pour construire un formulaire ?

Formulaire basé sur une table

La plupart des utilisateurs d’Access ont bien compris que le formulaire est une couche graphique qui repose sur une table, et qui permet de consulter les données de la table et, dans l’autre sens, de modifier les données de la table.

Sur le schéma ci-dessous, ceci est illustré par la flèche qui relie la table1 et le formulaire1 (les données circulent de la table vers le formulaire et, en cas de saisie/modification, du formulaire vers la table).

Formulaire basé sur une requête

Mais en fait, le formulaire (ou l’état) peut reposer sur 3 sources de données exactement (une seule à la fois) :

  • une table
  • une requête enregistrée dans la base de données (et donc visible sous l’onglet Requêtes).
  • une requête SQL (instruction SQL de type SELECT ... FROM ...)
Note
Sur le schéma, « requête » désigne indifféremment une requête enregistrée ou une requête SQL SELECT.

En pratique, il est souvent plus intéressant de construire un formulaire à partir d’une requête (cf. les 2 autres formulaires du schéma), parce que celle-ci est beaucoup plus riche que la table. Parmi les avantages :

  1. La requête permet de trier les enregistrements de façon permanente.
    Un formulaire basé sur une requête hérite des tris de cette requête.
  2. La requête peut comporter des champs calculés.
    Un formulaire basé sur une requête voit ces calculs comme des champs de table, et il peut les afficher dans des zones de texte.Avantages secondaires : une même requête peut servir à plusieurs formulaires ou états, et le fait de définir les calculs « le plus tôt possible » évite de les refaire pour un formulaire précis, puis pour un autre état… Economie de temps et de maintenance.
  3. Une requête peut associer plusieurs tables.
    Donc un formulaire reposant sur une requête peut afficher le contenu de plusieurs tables liées…

En résumé, lorsque vous envisagez de construire un formulaire, posez-vous des questions comme :

  • Est-ce que les enregistrements du formulaire doivent être triés ?
  • Est-ce que le formulaire doit afficher des calculs sur les enregistrements ?
  • Est-ce que le formulaire doit afficher le contenu de plusieurs tables liées ?

Si la réponse est oui (et ce sera souvent le cas !), préparez la requête qui va bien avant de vous lancer dans le formulaire.

  • Sur le schéma plus haut, on peut supposer que la requête1 a été construite pour trier le contenu de la table2, ce qui fait que le formulaire2 sera automatiquement trié.
  • On voit aussi que le formulaire3 est construit sur une requête qui associe 2 tables (imaginez une table Clients et une table Villes ; le résultat permet d’afficher l’adresse complète du client sur le formulaire).
Attention
Techniquement, si vous savez construire un formulaire à partir d’une table, vous savez le faire à partir d’une requête. Mais il y a quand même quelques pièges à éviter pour que tout fonctionne correctement. Un autre article bientôt !

Retrouver la source d’un formulaire ou d’un état

Comme il a été dit plus haut, un formulaire/état repose sur une table, une requête enregistrée (requête graphique), ou une requête SQL. L’article De quelle table ou requête dépend un formulaire ou un état ? explique comment retrouver cette source (et la modifier si nécessaire).

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *