Discussion :

[FMJ]

Bonjour,

Dans un formulaire où l'utilisateur lance à destination d'un SQL Server un traitement long de synchronisation avec de nombreuses requêtes SQL, j'ai souhaité inclure une progress bar et un chronomètre permettant à l'utilisateur de visualiser l'avancement et la durée de ce traitement de plusieurs minutes (et surtout d'avoir une idée approximative de la durée restante).

Pour la progress bar, j'ai utilisé un contrôle activex et pour le calcul du pourcentage d'avancement, je n'ai pas réinventé la poudre --> au début, calcul du nombre d'enregistrements puis insertion d'une clause if dans les boucles de recordsets qui met à jour la progress bar tous les 100, 200, ou etc. enregistrements. Ca marche bien.

Pour le chronomètre, j'ai un peu plus de mal.
Tout d'abord, j'ai essayé de passer par le Form_Timer et le GetTickCount du kernel32. Ca marche très bien pour des phases statiques mais ... comme VBA ne gère pas le parallel processing, Form_Timer perd la main dès qu'une sub s'exécute. Et donc le chrono se fige jusqu'à ce que la sub ait fini de s'exécuter --> méthode inutilisable à l'intérieur d'un traitement.
Ensuite, j'ai procédé comme pour la progress bar, en incrémentant le chrono dans les boucles de recordsets.

Cela fonctionnerait pas trop mal ... s'il n'y avait un gros souci. En fait, certaines requêtes chargent via le réseau des recordsets assez volumineux (de type rst.Open "SELECT ......"), ce qui rend plutôt très long leur temps de chargement (plusieurs dizaines de secondes). Et donc durant ce laps de temps où cette instruction est exécutée, la progress bar et le chronomètre sont bien évidemment scotchés. Le chrono prend ensuite x secondes d'un coup dès que le rst.open est chargé et que la boucle du rst est exécutée.



Au final, à moins de réaliser un recordset par enregistrement (ce qui serait contre-productif en terme de durée, puisque certaines tables font des dizaines de milliers de lignes), je ne vois pas comment je pourrais obtenir une progress bar et un chronomètre qui tiendraient la route ???!!!

Auriez-vous quelques suggestions lumineuses qui pourraient m'aiguiller ? Merci d'avance.

[paidge]

Ca marche très bien pour des phases statiques mais ... comme VBA ne gère pas le parallel processing, Form_Timer perd la main dès qu'une sub s'exécute. Et donc le chrono se fige jusqu'à ce que la sub ait fini de s'exécuter --> méthode inutilisable à l'intérieur d'un traitement.

Bonjour,
Question bête : As-tu regardé la fonction DoEvents ?

[FMJ]

Bonjour et merci pour ta réponse.

Malheureusement, DoEvents qui permet de passer momentanément la main à l'OS n'aide pas dans mon cas. Le problème ne vient pas d'un grand nombre d'itérations dans une boucle mais du fait qu'une seule instruction (un rst.open "SELECT ....") prend beaucoup de temps à charger un gros volume de données.

Comme j'indiquais précédemment, il serait possible de faire un rst.open "SELECT ..." pour une seule ligne, avec la clause WHERE qui va bien, mais cela serait très contreproductif compte tenu du nombre de lignes (si ajouter un chrono pour patienter entraîner une rallongement de X2 de la durée, c'est pas glop).


Autrement, je pourrais faire une boucle où le rst.open charge traite 100 lignes par chaque itération. Mais c'est compliqué du point de vue du requêtage car en SQL il y un "TOP x" (les x premiers) mais il n'existe pas un "TOP x y" (de la ligne x à la ligne y).
Hummmm, je vais quand même explorer cette piste car il me vient une petite idée. Mais il faut que je vérifie quel est l'impact en terme de durée de traitement supplémentaire.


Un début d'autre piste ? --> le multi-threating
http://access.developpez.com/sources...acc#creaThread

[Jean-Philippe André]

Bonjour,

j'ai une autre piste pour toi, les images d'attente ^^

L'excellent tuto d'Arkham46 devrait t'aider à faire patienter tout ton petit monde:
http://arkham46.developpez.com/artic...s/formattente/

[FMJ]

Bonjour et merci pour la proposition. On s'en tiendra aux images car l'autre solution proposée ne permet pas de résoudre mon pb : elle utilise un formulaire d'attente mis à jour toutes les X itérations du traitement.
Or dans mon cas, ce sont des traitements correspondant à une seule commande (rst.open "SELECT ....") qui génère l'essentiel du temps d'attente. Donc je ne peux donc pas y insérer de DoEvents permettant de mettre à jour le formulaire d'attente.

Il faut que je scinde cette commande en x commandes de durée largement inférieure pour pouvoir utiliser cette stratégie.

[marot_r]

Oui si Access n'a pas la main, il ne peut pas faire la mise à jour.

Deux idées :

• Non testé : ouvrir une fenêtre IE qui affiche une page HTML toute bête avec un GIF animé et un message "Merci de patienter".
  On peut peut-être utiliser un ActiveX qui affiche le navigateur dans le form.
• Ce que j'ai fait pour donner l'illusion de l'avancement progressif : avant le long traitement je fais avancer ma barre de progression de 50% de la distance prévue et quand le traitement est terminé je la met à 100%.

A+