Discussion :

[zooffy]

Bonjour à tous.

Je viens vers vous pour une question d'optimisation tout à la fois de codage, de performance et de maintenance.

J'ai une table centrale avec plein de données et plein de champs.
J'ai une série de formulaire (21) quasiment identique qui n'ont comme difference qu'une critère sur l'un des champs de la table. Là je viens de modifier 21 fois la source de donnée des formualire aprce que j'ai modifier la table de base en ajoutant un champs et donc, il faut replonger dans chaque Formulaire.

Alors je me pose la question : est ce que je ne ferais pas mieux de mettre en place une requête qui prend la clause WHERE globale (parce que chaque formualire dispose de critère identique en plus de celui qui diffère) et faire pointer tous mes formulaires dessus ?

Alors optimisaiton du codage, ça j'ai vu, si je dois changer une champ, j'ai une manip à faire et pas 21.
Par contre je me pose la question sur les performances : est ce que ce n'est plus fluide si on tape directement sur la table que si on tape sur une requête qui tape sur la table, ça rajoute une étape quand même.

Voilà, la question est posée, je pense qu'elle est surtout théorique, mais des fois que j'aurais loupé un truc ou que l'un d'entre vous aurait une idée brillante, je prends. Je me demande même si je devrais pas utiliser le princpe des sous formulaire parce que dans ma série de 21, ben j'ai des trucs qui se répètent.....

Merci pour votre aide et bon Lundi

[marot_r]

Bonjour.

Personnellement je n'ai jamais constaté de différence notable entre une table et une requête simple (requête sans calculs ni jointures) sur une table.
Et je t'inviterai à en effet mutualiser tes formulaires. L'éventuelle perte de performance sera à mon avis largement compensée par le gain de temps de maintenance.
Pour ce qui est de la solution, tu peux envisager :

1. 1 seul formulaire qui satisfait tout tes besoins (ma préférée).
   Tu affiches ou tu caches les champs par programmes.
   Tu changes la source ou tu filtres et tu tries par programme.
2. Plusieurs formulaire qui partage du code commun dans un module.
   Parfois on ne peut pas faire un seul formulaire sans que cela devienne extrêmement compliqué.
   Dans ce cas on a intérêt à mettre le code commun dans un module (ou un module de classe) et le réutiliser dans tous les formulaires.

A+

[zooffy]

Merci pour ton aide.

J'ai tout de même un souci pour mettre en place un système avec un formulaire unique et une gestion des champs à afficher ou pas.

J'ai du mal à créer un contrôle par code et l'ajouter dans le formulaire.
Je fais ça dans le Form_Current et I me dis que je ne pas le faire à ce moment là. Parce que, autant je peux avoir des fomulaire où les contrôle sont fixes, autant j'ai d'autre formulaire où les contrôles sont en fonction du volume de donnée que je remonte

Tu aurais une astuce ou un tuto qui tient la route ?

Bonne journée.

[marot_r]

Bonjour.

L'idée n'est pas de créer les contrôles par programme (ce qui est possible mais un peu lourd : ouvrir le formulaire invisible en modification, supprimer le vieux contrôle, ajouter le nouveau contrôle, enregistrer le formulaire, fermer le formulaire, ouvrir le formulaire pour l'utilisateur) mais de les rendre visibles par programme.
Donc le contrôle existe déjà et tu mets Me.MonControl.Visibile=True.

Dépendamment de l'esthétique que tu veux

• tu peux séparer tes contrôles dans l'écran final (il y a des "trous" là où les contrôles sont invisibles).
  Très facile à réaliser mais pas forcément très beau.
  Personnellement j'avais laissé les étiquettes visibles et mis les contrôles texte en gris sur fond ce qui rendait le texte invisible et affichait un rectangle gris à la place du "trou".
  C'était moins troublant qu'un contrôle perdu au milieu du formulaire parce qu'il est le troisième disponible.
• tu peux superposer les contrôles à la création.
  Cela rend la maintenance pénible.
• tu peux faire des contrôles très petits en création (ex : 1 mm x 1mm) et les rendre visibles et les redimensionner par code. (Mon préféré)
  C'est un bon compromis entre esthétique et maintenance.
• tu peux faire un champ "générique" indépendant dont tu changeras la source par code.
  Très adapté si tout tes champs sont du même type