Formulaire continu, requête et séquence d'ouverture

**olra72** · 07/10/2020, 10h39

Bonjour,

J'ai un formulaire f_AffaireSel continu, basée sur une requête simple - rf_AffaireSel - récupérant toute une table. La séquence d'ouverture est, comme d'habitude - Form_Open / Form_Load / Form_Activate / Form_Current / + Appel de la requête et affichage complet. Là, tout va bien !

Maintenant, je reprends le même formulaire et j'ajoute dans la zone d'en-tête un contrôle de texte éditable quelconque - disons ctl_Nature (avec une valeur par défaut) - et je modifie la requête rf_AffaireSel associée au formulaire pour qu'elle ne me retourne que les enregistrements dont la colonne "Nature" à la même valeur que [Formulaires]![f_AffaireSel]![ctl_Nature].

Malheureusement, avec cette modif, la séquence d'ouverture se réduit à Form_Open / Form_Load / Form_Activate. Il n'y a ni appel de Form_Current, ni appel de rf_AffaireSel ... donc mon formulaire reste désespérément vide*.

Mon hypothèse est que Access tente de vérifier (ou de lancer) la requête à un moment où le formulaire n'est pas encore vraiment disponible, donc à un moment où ctl_Nature n'existe pas encore, donc Access s'arrête après le Form_Activate ... sans afficher pour autant un message d'erreur. Qu'en pensez-vous ? Existe-t-il un moyen de corriger ce problème ?

Pour info, j'ai essayé un peu toutes les options associées au formulaire (Filtrage Oui/Non, Post traitement Oui/Non, etc.) mais je n'ai rien trouvé.

Cordialement,
Olivier

(*) Jusqu'à maintenant, j'avais contourné ça en appelant un Me.Requery explicite dans le Form_Activate mais j'aimerais comprendre ... et, en plus, ça entraîne une multiplication artificielle du nombre d'appels de rf_AffaireSel en cas de Deactivate/Activate.

**olra72** · 07/10/2020, 10h55

Mon hypothèse d'un problème de timing semble se confirmer !

J'ai fait l'essai suivant : J'ai dupliqué mon contrôle ctl_Nature dans un autre formulaire f_Filtre que j'ouvre avant et, dans rf_AffaireSel, je compare le champ Nature à [Formulaires]![f_Filtre]![ctl_Nature].

Et là, miracle, quand j'ouvre f_AffaireSel, je retrouve ma séquence complète (Form_Open / Form_Load / Form_Activate / Form_Current / + Appel de la requête .. avec le filtrage adéquat !).

Donc, comment demander à Access d'instancier complètement le formulaire (càd au moins la zone d'en-tête) et ses contrôles AVANT d'appeler la requête dudit formulaire de façon à ce que celle-ci puisse s'appuyer sur ces fameux contrôles ?

Cordialement,
Olivier

**olra72** · 07/10/2020, 11h26

J'ai fait un autre essai : J'ai inséré dans la requête rf_AffaireSel un appel à une fonction qui fait un Debug.print. A priori, ça me permet de voir QUAND cette requête est appelée et là, surprise, elle l'est une première AVANT MÊME le premier Form_Open !!! Donc, à ce moment, c'est sûr que ctl_Nature n'existe pas !

.. ce qui m'a mené à un troisième essai : J'ai carrément enlevé toute référence à une source de donnée dans le formulaire lui-même et, dans le code VBA de Form_Load, j'ai écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Private Sub Form_Load()
    Debug.Print Me.Name & " Form_Load"
    Me.RecordSource = "rf_AffaireSel"
End Sub

Au final, ça marche (je retrouve bien mes données correctement filtrées), par contre la séquence de démarrage devient : Form_Open / Form_Load / Form_Activate / Form_Current / Form_Deactivate / Form_Activate / Form_Current / + Appel des données. Donc c'est jouable, mais faut pas que je mette du code couteux dans ces fameuses fonctions .. ce qui m'arrive parfois !

En plus, ça a aussi l'inconvénient que pour éditer mon formulaire - comme il n'a plus de source de données - je n'ai plus aucune liste déroulante pour configurer les contrôles internes. Pas glop, pas Glop !!

Quelqu'un a une autre idée ? Quelqu'un qui connaîtrait bien les arcanes INTERNES d'Access ?

Cordialement,
Olivier

**olra72** · 08/10/2020, 08h09

Ah ? Pas de réponse d'un grand chef à trois plumes ? Dommage ...

J'ai continué à investiguer sur cette question des rapports entre l'appel des fonctions Open, Load, Activate et Current et l'appel (les appels) de la requête source ... et c'est pas triste ! Access a un petit côté "pas clair" dans ce domaine.

Par exemple, l'activation de l'onglet d'un formulaire ouvert appelle Form_Activate PUIS la requête source - alors qu'un Me.Requery volontaire appelle D'ABORD la requête source PUIS Form_Current. Dans tous les cas, il me paraîtrait plus logique d'appeler d'abord la requête source PUIS la fonction (Form_Activate ou Form_Current) ... ce qui permettrait de prendre des décisions sur la base d'un recordset à jour. Oui ? Non ?

Le mieux serait peut-être d'avoir une fonction (Form_Update ?) qui soit appelée systématiquement APRES la mise à jour du recordset. J'ai cherché mais pas trouvé ...

Autre exemple, un F5 dans un formulaire provoque l'appel à la requête source, puis Form_Current, puis un second appel à la requête source. On peut éviter ça en capturant le F5 et en le redirigant vers un Me.Requery volontaire (ce qui élimine le second appel à la requête) mais ça ne marche pas si le focus est dans l'en-tête du formulaire - pas dans un des contrôles de l'en-tête, non, juste dans la zone vide de l'en-tête. Dans ce dernier cas, pour éviter le double appel, il faut capturer le EntêteFormulaire_Click et rediriger le focus ailleurs.

Bref, tout ça fait un peu désordre. C'est pas trop grave quand la requête source est rapide ... mais, dans mon cas, et avec un réseau faiblard, ce n'est justement pas le cas.

Alors, s'il y a quelque part quelqu'un qui ait contribué au développement d'Acces et qui ait de bons tuyaux, je suis très très très intéressé ...

Cordialement,
Olivier

**Ric500** · 08/10/2020, 11h29

Bonjour,

Je viens de relire ton post pour la 2ème fois et j'avoue que je ne comprends pas ta demande: jusqu'ici les événements d'Access m'ont toujours paru suffisants et cohérents ainsi que leur chronologie.

Si ta demande concerne le rafraichissement d'un recordset après insertion d'un enregistrement par code (si l'enregistrement est ajouté via un formulaire, il se trouve de fait dans le recordsource), la procédure à suivre si tu veux te positionner dessus serait plutôt, après ajout, DANS l'événement Form_AFTERUPDATE de :
. repérer la clé de cet enregistrement (max du numéro auto, par exemple) dans une variable laCle,
. ajouter un me.Requery,
. et un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
With Me.RecordSetClone
   .FindFirst laCléAutoNum=laCle
   Me.BookMark=.BookMark
End With

Le mieux serait peut-être d'avoir une fonction (Form_Update ?) qui soit appelée systématiquement APRES la mise à jour du recordset. J'ai cherché mais pas trouvé ...

Je te rassure, cet événement existe bel et bien

Form_AfterUpDate (Après mise à jour du formulaire dans la feuille de propriétés).

Nom : Capture.PNG
Affichages : 94
Taille : 7,5 Ko

J'espère avoir répondu à ta demande, ("Vous pouvez répéter la question ?"

)

Bonne journée.

**olra72** · 08/10/2020, 17h07

Bonjour et merci à Ric500 pour la réponse,

A la base, j'ai une application Access segmentée Front-End/Back-End, en mode multi-onglets. Donc j'ouvre simultanément plusieurs formulaires, dont des formulaires continus et des formulaires à enregistrement unique.

La plupart des mes formulaires continus présentent, dans l'en-tête, divers champs permettant de filtrer la liste qui est dessous en se limitant aux seuls enregistrements ayant telle ou telle propriété.

Les requêtes associés à chacun de ces formulaires sont donc parfois assez complexes et potentiellement longs à exécuter (de 1 à 10 secondes, plus si le réseau est chargé).

A la base tout est parti d'un constat visuel : Quand j'ouvrais certains formulaires, ils s'affichaient une fois ... puis s'effaçaient et s'affichaient une deuxième fois.

Donc j'ai commencé à tracer précisément quand et combien de fois étaient exécutées les requêtes-sources associées à ces formulaires et ça pour trois circonstances : Lors de l'ouverture initiale, lors d'un simple Activate et lors d'un Me.Requery déclenché par le code du formulaire (par exemple en cas de changement d'un des champs de filtrage).

C'est ce qui m'a amené à tout ce qui précède. Voila ! C'est plus clair maintenant ?

Cordialement,
Olivier

**olra72** · 08/10/2020, 17h26

Ah oui ! Un point qui a son importance : Quand on fait le choix du multi-onglets, il arrive souvent que la même information (ie. le même champ) se voit - ou intervienne - dans plusieurs formulaires distincts, voire dans divers sous-formulaires d'un même formulaire !

Donc, quand on revient dans un formulaire via un Form_Activate, ou quand on se déplace dans divers sous-formulaires d'un même formulaire (et, là, il n'y a pas d'Activate qui tienne), il faut être sûr que le recordset local soit à jour et, en cas de doute, faire les Me.Requery qui vont bien (voire les Me.<controle>.Requery quand ces contrôles proposent des listes déroulantes elles-mêmes basées sur le contenu du recordset).

Du coup, j'ai eu tendance à mettre des Me.Requery de sécurité un peu partout. Quand c'est rapide, on s'en fiche ... mais quand ça commence à traîner .. ou à clignoter sous l'effet des rafraichissements, ça devient problèmatique, d'où mon intérêt soudain pour ce qui se passe réellement (et précisément) entre les formulaires, les sous-formulaires, les évènements et les requêtes-sources.

Tout ceux qui ont des requêtes-sources mono-table ou presque ne rencontreront sans doute jamais le problème. Moi, j'ai des requêtes-sources qui font intervenir cinq ou six tables, avec parfois deux à trois niveaux de sous-requêtes. C'est mal, Docteur ?

Tenez, pour le fun, voila une de mes requêtes-sources (r_AffaireRespContrat est une sous-requête assez mignonne aussi):

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT t_Affaires.*, t_Clients.NomComplet, Get_AffaireNbrDevis([ID_Affaire]) AS NbrDevis, Not IsNull([t_SGILAffaires].[Affaire_ID]) AS SGILAct, t_Clients.ID_Client
FROM ((t_Affaires LEFT JOIN r_AffaireRespContrat ON t_Affaires.ID_Affaire = r_AffaireRespContrat.Affaire_ID) LEFT JOIN t_Clients ON r_AffaireRespContrat.Client_ID = t_Clients.ID_Client) LEFT JOIN t_SGILAffaires ON t_Affaires.ID_Affaire = t_SGILAffaires.Affaire_ID
WHERE (((t_Affaires.Nature)=[Formulaires]![f_AffaireSelect]![ctl_Nature]) AND ((IIf(IsNull([Formulaires]![f_AffaireSelect]![filtre_CA]),True,[CA_TLA_ID]=[Formulaires]![f_AffaireSelect]![filtre_CA]))=True) AND ((IIf([Formulaires]![f_AffaireSelect]![filtre_MesAff],[CA_TLA_ID]=Get_gv("TLA"),True))=True) AND ((IIf([Formulaires]![f_AffaireSelect]![filtre_Gen]=-2,True,[Formulaires]![f_AffaireSelect]![filtre_Gen]=[Generique]))=True) AND ((IIf([Formulaires]![f_AffaireSelect]![filtre_Ext]=-2,True,[Formulaires]![f_AffaireSelect]![filtre_Ext]=[Externe]))=True) AND ((IIf(IsNull([Formulaires]![f_AffaireSelect]![filtre_Etats]),[Etat_ID]<>"SLD" And [Etat_ID]<>"ANN",[Etat_ID]=[Formulaires]![f_AffaireSelect]![filtre_Etats]))=True) AND (([ID_Affaire] & " " & [Libelle] & " " & [t_Affaires].[Societe] & " " & [t_Affaires].[Unite] & " " & [t_Affaires].[Projet] & " " & [t_Affaires].[SousProjet] & " " & [AffaireTypeS].[Value] & " " & [VALs] & " " & Nz([r_AffaireRespContrat].[NomComplet])) Like "*" & [Formulaires]![f_AffaireSelect]![filtre_Divers] & "*"));

**Ric500** · 08/10/2020, 17h35

OK, je comprends mieux

Du coup, j'ai eu tendance à mettre des Me.Requery de sécurité un peu partout.

Effectivement, c'est de ce côté qu'il faut chercher à mon avis.

Plutôt que d'actualiser ainsi la source de données quand je bouge une donnée dans un formulaire, j'ai plutôt tendance à utiliser me.refresh que me.requery, ce qui n'actualise que l'enregistrement en cours sans avoir à rafraichir toute la source de données sous-jacente.

Donc utiliser cette méthode lors d'un form_Current me paraît étrange, sous réserve d'une modification de l'enregistrement courant atteint lors du déplacement par un code qui changerait une donnée à ce moment-là et justifierait le me.refresh.

**Ric500** · 08/10/2020, 17h40

Tout ceux qui ont des requêtes-sources mono-table ou presque ne rencontreront sans doute jamais le problème. Moi, j'ai des requêtes-sources qui font intervenir cinq ou six tables, avec parfois deux à trois niveaux de sous-requêtes. C'est mal, Docteur ?

J'ai parfois des requêtes bien plus complexes qui s'affichent sans délai, le seul truc chronophage selon le nombre de lignes renvoyées, pourrait être le "GetAffaire" qui s'effectue à chaque ligne.

Après, bien poser ses index dans les tables peut aider. Dans les cas extrêmes, je lance un événement qui crée une table temporaire (effacée à chaque filtrage) et là je joue sur du local.

**olra72** · 09/10/2020, 08h32

Ça empire chaque jour !

Histoire de vous faire une démo, j'ai créée une base "from scratch", avec les formulaires minimaux et les traces ad-hoc. Je voulais vous la passer en disant "regardez-moi ça !" ... et je n'ai pas trouvé DU TOUT ce à quoi je m'attendais ! Ça marchait (presque) comme ça devrait.

Alors, j'ai ajouté progressivement divers trucs (sans aucun rapport, hein !) que je fais dans la vraie afin de me rapprocher par étapes de ma véritable appli ... et j'ai vu réapparaître certaines des étrangetés constatées.

Comme solution, pour l'instant, j'envisage le suicide

Je fais le point et je reviens vers vous ! En attendant, priez pour moi !