DoCmd.Openform - clause Where versus OpenArgs

Bonjour,

J'ai un formulaire dont la source de donnée est une requête assez complexe sur plusieurs tables, et dont un champ appelait une fonction écrite en VBA (une fonction de comptage trop farfelue pour être réalisée via les "Totaux" habituels, en tout cas pas à mon niveau de compétence).

Lors de mes premiers essais, j'ai utilisé la clause Where pour afficher les données relatives à un enregistrement précis.

Vu les performances - désastreuses - j'ai tracé les appels à la fonction et - surprise - j'ai découvert que ma fonction VBA était appelée pour TOUS les enregistrements de ma requête et pas seulement sur celui que visait la clause Where ... exactement comme si le recordset du formulaire comprenait en fait TOUS les enregistrements et que la clause Where ne servait in fine qu'à "positionner" le formulaire sur le seul enregistrement ciblé.

Du coup, je me suis rabattu sur l'OpenArgs pour positionner une valeur de filtrage que j'ai intégrée explicitement dans la requête du formulaire. Dans ce cas, ma fonction VBA n'est appelée qu'une fois et j'imagine que le recordset du formulaire ne contient en tout et pour tout QUE l'enregistrement ciblé.

Bref, utiliser la clause Where de l'OpenForm et insérer une clause WHERE dans la source de donnée du formulaire via un paramètre reçu par OpenArgs ne sont pas du tout comparables ! Si le formulaire ne vise qu'a afficher les données d'un objet précis, et non à naviguer entre tous les candidats possibles, la deuxième approche est de loin préférable (surtout quand le formulaire est kaffi de sous-formulaires).

Ça parle à quelqu'un ce genre de détail ? J'ai relu tout ce que j'ai trouvé comme doc et je n'ai trouvé aucune mention de ce genre de subtilité ... mais j'ai peut-être mal cherché ...

Cordialement,
Olivier

Bonjour,

Effectivement les fonctions perso sont très pratiques dans les requêtes mais à banir des recordset s'il y a bcp de lignes :aie:

Dans ton cas il me semble que le plus simple aurait été d'appeler la fonction au niveau du champ affiché dans le form ;)

Hum ? Quand il s'agit de formulaires en mode continu, je ne vois pas trop comment appeler la fonction dans le code VBA du formulaire. Faut-il rebalayer (et compléter) le recordset dans le Form_Open, le Form_Load ou le Form_Activate ??

En plus, je suis dans une application à onglets où j'ai plusieurs formulaires ouverts en même temps et, bien sur, un formulaire peut afficher des données partiellement dépendantes de données modifiables dans un des autres (d'où l'usage intensif que je fais déjà du Form_Activate).

Quoi qu'il en soit, mon interrogation de fond reste en suspens : quand j'utilise un set de données filtrées par une clause Where lors de l'ouverture d'un formulaire, quelle est la taille réelle du recordset sous-jaccent ? Rien que les résultats filtrés ou le résultat intégral de la requête (ie. sans la clause Where) ?

Cordialement,

PS : En fait, j'aimerai bien disposer d'un outil de monitoring qui m'indique quelles sont les requêtes (et sous-requêtes) qui ont été lancées, combien de temps elles ont pris et combien d'enregistrements elles ont retournés. Est-ce que ça existe ?

Citation:

---

Envoyé par olra72

Hum ? Quand il s'agit de formulaires en mode continu, je ne vois pas trop comment appeler la fonction dans le code VBA du formulaire.

---

Dans la source d'un champ on peut écrire =mafonction(monchamp)
Les performances ne sont pas très bonnes non plus mais au moins c'est géré au niveau de l'affichage

Citation:

---

Envoyé par olra72

PS : En fait, j'aimerai bien disposer d'un outil de monitoring qui m'indique quelles sont les requêtes (et sous-requêtes) qui ont été lancées, combien de temps elles ont pris et combien d'enregistrements elles ont retournés. Est-ce que ça existe ?

---

Je connais avec une base SQL server mais pas access, désolé. Ceci dit cela existe peut-être ;)

Bonjour

Citation:

---

J'ai un formulaire dont la source de donnée est une requête assez complexe sur plusieurs tables, et dont un champ appelait une fonction écrite en VBA ...

---

Ton formulaire est il seulement utilisé en consultation ?
si oui, je conseille avant d'ouvrir le form de mettre les données filtrées dans une table temporaire et de mettre cette table temporaire en données source du form.

CDLT

Salut,

plus pratique pour garder trace des informations : les tables de parametres :)

Avec du code dans les Form_Load().