Améliorer les performances d'ouverture des formulaires

Numéro d'article: 465335 - Voir les produits auxquels s'applique cet article
Ancien nº de publication de cet article : F15335
Agrandir tout | Réduire tout

Résumé

INFORMATION TECHNIQUE :

Comment augmenter les performances d'ouverture des formulaires avec
Microsoft Access 95 ?

Avec Access 2.0, tout le code Access Basic contenu dans les modules est
chargé en mémoire au démarrage de l'application.
Par contre, Visual Basic pour Application, charge le code en mémoire,
uniquement lorsque l'application en a besoin, on parle alors de Gestion
dynamique de la mémoire.

Lorsqu'une fonction contenue dans un module est référencée
(Exemple : Call Mafonction), ou même lorsqu'une variable globale va être
utilisée dans un formulaire, VBA charge TOUT le code du module dans la
mémoire.

En d'autres termes, si dans votre formulaire vous faites appel à une ou
plusieurs procédures ou plusieurs variables contenues dans différents
modules, VBA chargera en mémoire tous les modules, augmentant
significativement le temps de chargement du formulaire.

REMARQUE :
- Dans Access 7.0, il est possible à partir d'une feuille de module de
faire référence à des procédures contenues dans des librairies externes
par le menu Outils Références.
- Vous pouvez référencer des modules, ou des variables, sans
jamais y faire appel, cela ne changera pas le temps de chargement.
- Si une procédure ou une variable globale n'est jamais utilisée, VBA
chargera quand même tout le module dans lequel elle est contenue.


Pour augmenter les performances de chargement d'un formulaire Access 95,
il existe plusieurs méthodes que l'on peut appliquer avec ses avantages et
ses inconvénients.

1) Pré-chargement des formulaires :
Lors du chargement de l'application, vous pré-chargez en mémoire les
formulaires avec l'option invisible, et vous les rendez visibles et/ou
invisibles lorsque l'application en à besoin ou n'en a plus besoin.

Cette méthode permet un chargement rapide du formulaire, puisqu'il est
lui-même déjà en mémoire, et que Visual Basic, n'a plus besoin de charger
les modules.

Par contre, le démarrage de l'application risque d'être plus long.
Cette méthode convient à des systèmes dotés d'une capacité mémoire
relativement importante.

2) Divisez les modules important, en plusieurs petits modules :
Si dans un formulaire, vous faites appel à une seule procédure contenue
dans un module qui en comporte un grand nombre, tout le module sera chargé
en mémoire.
Il est donc nécessaire dans ce cas précis, d'intégrer la procédure appelée
dans un module peu volumineux pour augmenter les performances d'ouverture
d'un formulaire.

3) La dernière méthode consiste à utiliser la syntaxe :
Application.Run "Projet.MaFonction",Param1,Param2,....

En effet, lorsque vous utilisez cette syntaxe le module qui inclut la
fonction "MaFonction" n'est chargée qu'au moment où Visual Basic exécute
la ligne Application.Run.
(Pour plus d'informations sur la commande "Run", reportez-vous à l'aide de
Microsoft Access pour Windows 95)

En utilisant cette méthode, le code est chargé uniquement lorsque
l'utilisateur l'exécute, mais jamais lors du chargement du formulaire.

Néanmoins, l'utilisation de cette méthode comporte quelques restrictions.
Toutes valeurs retournées par la fonction seront ignorées par Microsoft
Access, et il vous sera impossible de passer en paramètre une variable
définie par l'utilisateur.



Les différentes méthodes, ne sont données qu'à titre indicatif. Ce n'est
pas parce qu'elles doivent améliorer les performances d'ouverture d'un
formulaire, qu'elles le feront forcement. Tout dépend du contexte dans
lequel sera exécuté l'application et d'un certain nombre de facteurs
extérieurs qui peuvent influer sur les performances générales de
l'application.

Néanmoins, elles pourront certainement vous aider à choisir la bonne
stratégie de développement pour tel ou tel formulaire.
Puisque chaque méthode apporte ses avantages et ses inconvénients,
vous serez peut-être amené à les combiner pour améliorer les performances
de vos formulaires.


Autres considérations importantes :
-----------------------------------
Avant de tester les performances d'ouverture de vos formulaires il est
impératif de bien comprendre les mécanismes de compilation.

Microsoft Access stocke le Code VBA dans deux états différents : compilé
ou décompilé.
Une application est dite décompilée dès que vous modifiez un formulaire,
un état, un contrôle, ou un module, dés que vous ajoutez un formulaire, un
état, un module, ou une procédure de formulaire, dés que vous supprimez ou
renommez un formulaire, un état, un contrôle, un module, ou une procédure
de formulaire. Si vous ne sauvegardez pas les modifications, l'état de
compilation du code VBA est préservé sur Disque.

Vous devez également garder à l'esprit, que si une application (le fichier
MDB) est renommée, l'application sera automatiquement décompilée. Ceci
signifie que si vous compactez votre application sous un autre nom, vous
perdrez la compilation. Pour prévenir ce phénomène, renommez le fichier
compacté avec le nom original.

Lorsque l'application est dans un état dit décompilée, elle s'exécutera
moins rapidement, car VBA, compilera le code a la volée. Ce phénomène peut
entraîner une ouverture de formulaire beaucoup moins rapide que si
l'application était dans un état compilée.

Une application décompilée utilisera également plus de mémoire. En effet
si une application est entièrement compilée, seul le code compilé sera
chargé en mémoire. Par contre pour les applications décompilées, le code
dit décompilé est chargé en mémoire, puis l'état de compilation est créé
et chargée en mémoire dés que nécessaire. Donc les deux états, compilé et
décompilé, sont chargés en mémoire.

Comme nous venons de le voir, si vous compilez tous les modules, VBA
chargera en mémoire tous les modules. Comme il ne gère pas le déchargement
dynamique, ceci risque de fausser vos tests d'ouverture de formulaire,
puisque VBA n'aura pas à recharger les modules.
Il est donc fortement conseillé avant de faire des tests d'ouverture, de
fermer la base de données, pour décharger le code de la mémoire, puis de
d'ouvrir de nouveau la base et de commencer les tests.

Il est important de tenir compte que lors de la fermeture du formulaire
VBA ne décharge pas le code, ce qui entraîne une seconde ouverture du
formulaire plus rapide.

Propriétés

Numéro d'article: 465335 - Dernière mise à jour: lundi 15 avril 1996 - Version: 1.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Access 95 Standard
Mots-clés : 
fmr pgm KB465335
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Exclusion de responsabilité concernant les contenus obsolètes dans la Base de connaissances
Cet article concerne des produits pour lesquels Microsoft n'offre plus de support. Il est par conséquent fourni « en l'état » et ne sera plus mis à jour.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com