Discussion :

[GD91]

J'ai converti les macros d'une application Access en VB

Même en local avec un seul utilisateur, l'affichage de formulaires, même simples, est devenu beaucoup plus long (plusieurs secondes, instantané auparavant) lors du premier affichage. Pour les affichages suivants du même formulaire c'est presque aussi rapide qu'avant!

Des idées?

[argyronet]

Bonjour,

As-tu relu le code une fois converti ? Te sembles t-il correct ?
Ouvrir un formulaire sans code (double-clic) est-il aussi long ?

Argy

[GD91]

J'ai écrit tout le code; Je n'ai utilisé la conversion automatique que pour avoir le premier jet.

C'est effectivement long même pour un formulaire sans code et marqué sans module!

énigmatique

Je suis en train de travailler sur la modularité des modules ....

[argyronet]

C'est effectivement long même pour un formulaire sans code et marqué sans module!

Ce n'était pas ma question...
Est-ce que l'ouverture d'un formulaire A ouvert par le code transformé et l'ouverture de ce même formulaire depuis la liste des formulaires est le même selon toi ?

Pour moi, il n'y a aucun rapport probable entre le temps de réponse d'une macro OuvrirFormulaire et d'un DoCmd.OpenForm.
Ton problème vient d'ailleurs...
Argy

[GD91]

Que j'ouvre le formulaire par le code ou directement dans la liste des formulaires, le temps est sensiblement le même : trop long

Dans l'ancienne version, c'était très rapide

Cela pourrait il être du à un encombrement de la mémoire par les modules chargés?

J'ai sorti la liste des modules chargés (code ci-après) et je trouve dès le début - avant d'avoir lancé l'application - un grand nombre de modules de classe liès à des formulaires ou des états qui n'ont pas été utilisés!?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Sub Modules_chargés()
    Dim i As Integer
    Dim modOpenModules As modules
    Dim liste As String
    Set modOpenModules = Application.modules
 
    For i = 0 To modOpenModules.Count - 1
        liste = liste & modOpenModules(i).Name & vbCrLf
    Next
    MsgBox "Modules ouverts:" & vbCrLf & liste
End Sub

[argyronet]

Il y avait tant de macros que cela ???
Ca me surprend un peu...

1/ As-tu gardé l'ancienne version (avec macro) ?
Si oui, réessaye de nouveau pour comparer (encore)

2/ La base est-elle scindée ? (Appli sur ton poste et BDD sur serveur)

3/ Si (2) Y a t-il des tables attachées exploitant ODBC ?

Argy

[GD91]

J'ai bien les deux versions
La différence de temps de réponse est flagrante

La base n'est pas scindée
Il n'y a pas d'ODBC

Quant au code que j'ai utilisé pour lister les modules, il donne tous les modules de l'application - chargés ou pas ...

[argyronet]

Quant au code que j'ai utilisé pour lister les modules, il donne tous les modules de l'application - chargés ou pas ...

Oui, mais on n'en tient pas compte, ça n'a pas d'importance...
Quelle la 1ère procédure exécutée par ton appli :

Code Macro:

Code VBA:

Enfin où est-ce que c'est très lent en somme (donne le code)...

Argy

[GD91]

Ce qui est devenu très lent, c'est l'ouverture d'un formulaire très simple , sans code qui consiste à visualiser une table en sélectionnant les enregistrements par une valeur issue d'un formulaire; La sélection est faite dans la requête sous jacente et le champ qui est testé est indexé.

Cette ouverture est lente que l'on ouvre le formulaire directement dans la liste ou qu'on le fasse par docmd.openform ...

Dans l'ancienne version c'est instantané (ou presque)

Ce phénomène ne se produit qu'à la première ouverture du formulaire.

Au moment de l'ouverture du formulaire, j'entends le disque pédaler pas mal ... c'est pourquoi j'ai pensé à un encombrement de la mémoire .... peut être du aux modules. En scidant les modules en granules plus petits, il y a une (légère) amélioration ....

[argyronet]

Je m'égare peut-être mais là...

Humm, voyons, as-tu essayé de compacter/réparer ta base ?
Ce que tu me dis la ressemble plus à un problème de clusters éparpillés pour ton fichier MDB... Ta base est-elle volumineuse ?
Comment se porte ton disque dur ? A quand remonte la dernière défragmentation ?

Argy

[GD91]

C'est vrai qu'il y a de quoi être perplexe

J'ai compacté la base
Mon disque est en NTFS

La base fait environ 50Mo après compactage

Mais tout ça était efefctivement vrai dans la version 'Macro'

J'ai vu, dans les conseils Microsoft , que pour optimiser les performances, il valait mieux utiliser des macros ... !!!!??

[Tofalu]

Ta base est mise en réseau ?

Tout comme argy, je ne pense pas que cela viennent de la conversion des macros à moins que celle ci n'ait endommagé le fichier

Sinon solution simple : ne pas convertir les macors

[argyronet]

Merci Tof pour ton appuie...

Bon, et je réitère ma question, y a t'il tant de macros que cela à convertir ?

As-tu essayé d'exporter tous les objets sauf les macros dans une nouvelle base et constater les performances. Si elles sont identiques à la version avec macros alors réécris le code proprement à la main...

J'ai vu, dans les conseils Microsoft , que pour optimiser les performances, il valait mieux utiliser des macros ... !!!!??

Ca c'est un scoop !!!
Bon, ben chers développeurs VBA, vous avez plus de travail

Argy

[GD91]

Oui, il y a beaucoup de macros, c'est une application de gestion assez complète

Mais ceci étant, je viens de me rendre compte que sur un autre ordinateur je n'ai pas ce problème.

Sinon, l'ordinateur à problème semble fonctionner normalement et je vérifie régulièrement la non présence d'espions ....

??????

[GD91]

J'ai fini par trouver un truc qui s'appelle hbtools que j'ai eu un certain mal à extirper! Il renaisait toujours de ses cendres ...
Depuis ça marche convenablement!

J'ai un peu du mal à y croire ....

[argyronet]

J'ai fini par trouver un truc qui s'appelle hbtools ...
J'ai un peu du mal à y croire ....

C'est également mon avis...
Enfin, tant mieux.

Argy