Discussion :

[lololebricoleur]

Bonjour,

J'ai développé l'application de gestion de ma boite à partir d'Access.
mono fichier, 150mo en gros, hébergé sur un serveur et 8 utilisateurs connectés en moyenne.
Mais ça rame.
Alors je voulais fractionner la base.
Le processus se passe bien mais, au final, ça rame encore plus et je ne comprend pas pourquoi !?
Ça devrait être l'inverse en disposant des formulaires, requêtes, états...en local et en ne faisant transiter que les données pas le réseau non ?
D'où pourrait venir le problème selon vous ?
La base compte environ 200 tables, ça pourrait venir de là ?
Je n'utilise pas de macro, que du vba et des requêtes Access (une peu de SQL en VBA, ça peut jouer ?

Merci de votre aide et de vos conseils pour optimiser.

[EricDgn]

Bonjour,
Pas de réponse précise à proposer.
Un point: la base sur le serveur est-elle compactée régulièrement? Comme désormais elle est "attachée" pour tous les utilisateurs, elle ne sera plus compactée automatiquement (vu qu'elle n'est plus "ouverte" puis refermée).
Quelques pages qui traitent de ce sujet:
Guide d'optimisation de vos applications Microsoft ACCESS
Recipe 8.7 Accelerate Multiuser Applications (réduire le trafic réseau en réduisant au maximum le nombre d'enregistrements contenus dans le RecordSource de chaque formulaire)
Tips for Faster Microsoft Access Databases
... que vous avez sans doute déjà consultées.
Cordialement.

[marot_r]

Bonjour.

Cela arrive parfois sans que j'en ai bien saisi les causes.
J'ai eu le cas avec un seul utilisateur (moi) ou la BD fractionnée était signficativement plus lente que la non fractionnée.

Aussi as-tu un ralentissement global ou seulement sur certains formulaires ?

Si c'est sur certains formulaires, les 2 ralentisseurs les plus innatendus étaient :

• Les sous-formulaires.
• Les listes déroulantes.

Dans les deux cas, la solution a consistée à n'aller chercher l'info que au moment où j'en avais vraiment besoin pas au chargement du formulaire.

Tu peux aussi lancer l'analyseur de performance de Access, il a parfois de bonne suggestion.

A+

[lololebricoleur]

Oui, j'ai effectivement fouiller un peut partout pour essayer de trouver des explications et des solutions mais sans sans résultats probants ou sans vraiment tout comprendre j'avoue.

Je viens de refaire des test en fractionnant et en appliquant 2 ou 3 astuces dénichées au fil de mes recherches. Il semble que cela se passe mieux.
Déjà, la base n'est plus moins lente en fractionnée qu'en non fractionnée.
Notamment, j'ai désactiver l'option de rechercha automatique des noms, les sous tables (je savais même pas que ce paramètre existait)...
Et ça semble influencer les performances.
Je vais utiliser l'analyseur de performance mais je m'en méfie car j'ai peur qu'il me propose des solutions avec des effets pervers.
Je continue de chercher. Merci de votre aide.

[marot_r]

Bonjour.

Je vais utiliser l'analyseur de performance mais je m'en méfie car j'ai peur qu'il me propose des solutions avec des effets pervers.

Si tu as des doutes, tu peux ne pas les appliquer mais chaque fois que je m'en suis servi je n'ai eu que des bonnes idées.
Bon dès fois il suggère de changer les types de données texte en nombre mais comme je l'ai dit plus tôt, tu n'est pas obligé de faire ce qu'il dit :-).
La suggestion n'est pas mauvaise en soi mais je préfère garder le contrôle de mes types.

A+

[lololebricoleur]

Merci Marot,

Dans les suggestions, idées... de l'analyseur, qu'elles sont celles qui ont le plus d'importances selon toi ?

Il me propose notamment :
- De compiler l'appli avant l'enregistrement
- De relier certaines tables
- une ou deux fois, d'indexer une rubrique
- de supprimer des section dans des états
- Il me parle aussi de "paramètre de propriété" qui serait trop long (sur des états)
- Il me suggère d’utiliser l'instruction "Option explicit" (à insérer en début de code si je dis pas de bêtises) pour des états, modules...

Merci de ton aide

[marot_r]

Merci Marot,

Dans les suggestions, idées... de l'analyseur, qu'elles sont celles qui ont le plus d'importances selon toi ?

Oui mais comme je l'ai dit il s'agit de suggestions donc tu dois exercer ton jugement pour déterminer ce que tu veux faire ou pas.
Je te donner mon avis à mettre dans ton contexte.

Il me propose notamment :

- De compiler l'appli avant l'enregistrement

C'est un minimum. Cela ne coute absolument rien et rend l'appli plus efficace.

- De relier certaines tables

À voir si c'est pertinent dans ton modèle de données.

- une ou deux fois, d'indexer une rubrique

Généralement une bonne idée car cela peut accélerer les requêtes.
Là aussi cela ne coûte pas grand chose de le faire.

- de supprimer des section dans des états

Peut-être mais cela peut interférer avec une conception "logique" (ou "naturelle") de ton état.
Si tu n'as pas de problème de performance pour cet état et que tu n'y vois pas de gain en "lisibilité" ou "compréhensibilité", je n'y toucherai pas.
Avec la puissance des machines actuelles, il faut optimiser la conception pour l'humain pas pour la machine.

- Il me parle aussi de "paramètre de propriété" qui serait trop long (sur des états)

À voir, je n'ai jamais eu de suggestion de ce type.

- Il me suggère d’utiliser l'instruction "Option explicit" (à insérer en début de code si je dis pas de bêtises) pour des états, modules...

Cela devrait être obligatoire.
C'est une des options de l'éditeur de code que je t'invites à activer.

Option Explicit te force à déclarer tes variables avant de les utiliser et c'est une TRÈS bonne chose car cela évite des bugs du à une mauvaise orthographe du nom.

À mes débuts j'ai perdu 15j avec un code BASIC où j'avais tapé par erreur P1 à la place de PI.
À l'exécution P1 était silencieusement intialisée à 0 au lieu que ce soit 3.14 ce qui avait des conséquences désagréables sur le résultat.
Ce jour là j'ai compris pourquoi Pascal et COBOL te forçait à faire la déclaration et dés que BASIC l'a permit je l'ai fait.

Une methodes simple pour la mettre en oeuvre cette recommandation, après avoir fait une sauvegarde de sécurité, est :

1. Aller dans l'éditeur de code
2. Lancer Recherche/Remplacement ([ctrl][h]).
3. Remplacer Option Explicit par rien dans tout le projet.
   Cela va supprimer tous les Option Expllcit qui pourrait être là.
4. Puis de remplacer Option Compare Database par Option Compare Database : Option Explicit dans tout le projet.
   Option Compare Database est présent dans tous les modules donc cela va ajouter Option Explicit à tous les modules sans que tu ais de passer dans chacun d'eux.

Après tu demandes une compilation du projet et tu fais les déclarations nécessaires quand le compilateur crie.
Ça peut être un peu long mais c'est du temps bien investi qui va te sauver du temps en maintenance.

Accessoirement et même si le gain est minime, déclarer tes variables et les typer aide le compilateur à faire un code machine (ce que ton processeur execute vraiement) plus efficace.

Si tu ne sais pas quel type utiliser, déclare ta variable as Variant.
Cela signale à au lecteur que justement tu ne savais quel était le type, pas que tu as simplement oublié de la typer.
Cela signale aussi au lecteur qu'il ne peut pas faire de supposition sur ce que va contenir la variable et que cela peut-être n'importe quoi.

A+

[lololebricoleur]

Merci pour ton aide Marot,

J'ai bien progressé en appliquant les conseils et astuces.
J'ai déjà un premier résultat très encourageant
La base fractionnée fonctionne maintenant mieux que la base la base d'origine.
Et il me reste encore des pistes à explorer donc la solution se niche dans des "détails" qui, cumulés, peuvent anéantir les performances.

Merci encore