Discussion :

[ericain]

Bonjour!

J'ai une bdd qui fonctionne très bien et quand elle est sur le disque dur tout va très vite, c'est nickel.
Afin qu'elle soit multi-utilisateur, je l'ai installé sur un disque réseau.
Mais voila le réseau est incroyablement lent (fermer un etat prend environ 30s !!!!!!!!!!!! ).
Y a t'il une solution pour contourner ce problème? genre installer l'application sur tous les postes et effectuer un rappatriement automatique des données tous les soirs à minuit lorsque le réseau est plus rapide?

Bref c'est la m.... y a déjà pleins d'utilisateurs qui se plaignent de la lenteur de mon application, mais j'y suis pour rien!!!!!

[ARO]

Bonjour,

As-tu séparé ta base de données, c'est à dire les tables sur le serveur et les formulaires, états,... sur les postes clients ?

Regardes à cette adresse, pour des conseils d'optimisation :

http://access.seneque.free.fr/optimisation.htm


ou ceci, trouvé sur le web :

Je vous livre ici un petit condensé de mes recherches sur
divers sites, concernant ce pb (récurent avec ACcess2000,
quoiqu'on en dise).
Chez moi, c'est la dernière solution qui a fonctionné,
après des semaines à me gratter le cheveux .
**********************************
Causes connues de la lenteur d'une appli access avec
tables liées
Même parfois un peu loufoque, ces solutions ont toutes
été éprouvées ! Ne rien laisser au hasard, donc.

- sur le serveur, vérifier l'écran de veille: un écran de
veille gourmand (genre Boules 3D), sur NT, peut accaparer
jusqu'à 90% du CPU. Incroyabe mas vrai!
Solutions: désactiver l'écran de veille ou affecter
un écran de veille type Black Screen, peu glouton

- dans les tables, passer en mode création, afficher les
propriétés des tables, et régler la propriété Sous
feuille de données (sub data sheet je crois) sur [Aucun]
([none])
Access a tendance à rapatrier toutes les "sous-
données" (tables en relations un à plusieurs en
général) , ce qui alourdit considérablement le trafic
d'infos dans les tuyaux

- toujours dans les tables, mais aussi dans l'appli:
Outils/Options/onglet général .. s'assurer d'avoir
décoché l'option "suivi correction automatique des noms"
(attention, il est possible que certains états perdent
leur mise en forme) .. conséquence, certains états
peuvent s'ouvrir jusqu'à 4 fois plus vite (merci
Microsoft)

- dans la série incroyable, on poursuit: placer la base
de données source (backend) sur la racine du serveur
plutôt que dans une multitude de sous-répertoire.
a compléter par la réduction du nom du fichier source :
ex: c:\repertoire1\repertoire2\repertoire3\repertoire4
\MaBaseDeDonnéesSourceAccess2000.mdb sera moins
performant (tables liées) que c:\repertoire1\Base.mdb

- Anti-virus: un cas fréquent de lenteur: si vous
disposez de norton Anti virus (une des 3/4 dernières
versions), s'assurer que le fichier source sera exclus du
scan
et que l'anti-virus n'analyse QUE les disques locaux, et
pas les lecteurs réseau

- S'assurer que vous disposez bien du dernier moteur Jet,
à moins que, puisque vous me parlez d'internet, vous
n'utilisiez le moteur MSDE
Q302496 ACC2000: Queries Slower After You Install MS Jet
4.0 SP4 or SP5
<http://support.microsoft.com/support/kb/articles/q302/4/9
6.asp>

- ce qui a fonctionné pour moi (mais pour internet,
faudra adapter ;-) ):
la base front end, lorsqu'elle tente d'accéder à la base
backend (tables liées à un fichier source), rencontre un
fichier lockFile (*.ldb)
Access tente alors de supprimer ce fichier, mais n'y
parvient pas (puisque quelqu'un est déjà connecté sur la
base source). Après une quinzaine de tentatives,
infructueuses, Access renvoie enfin le jeu
d'enregistrement. Pour éviter cela, voilà ce que j'ai mis
en place:
afin d'établir une connection permanente avec la base en
backend, et donc de prévenir ce probème, créez

-un formulaire, appelons-le "frmdummy" (formulaire
stupide ;-) )
- une table "tbldummy" (avec un champ simple, n'importe
quel format, n'importe quel nom)
-dans un module standard, déclarez une variable globale
de type recordset
ex: Public rsAlwaysOpen As
Recordset
-Dans l'évènement sur ouverture du formulaire frmdummy
(OnOpen), ouvrez un recordset
Private Sub Form_Open(Cancel As Integer)
Set rsAlwaysOpen = CurrentDb.OpenRecordset
("DummyTable")
End Sub

-Dans l'évènement sur fermeture du formulaire frmdummy
(OnClose), fermez le recordset
Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

- au lancement de la db, ouvrez ce formulaire en premier,
avec visible=false
ce formulaire restera ouvert jusqu'à la fermeture de
l'appli.

Résultat: un traitement de 5 à 10X plus rapide ...

[léonardgénie]

J'ai eu le même problème avec trois ordi "costaud" sous XP, dont l'un hébergeait les tables.
Après quelques touffes de cheveux arrachés, j'ai fini par virer mes tables sur un 4e ordinosaure sauvé de la poubelle (PI 130, 32 Mo RAM ! sous W 98 !) et ça marche très, très bien.

[ericain]

Merci beaucoup!
Je vais essayer tout ca, et je vous tiens au courant pour le résolu quand ca marchera!

[ericain]

Et bien j'ai mis en place la plupart des modifs proposées dans les 2 documents et j'obtiens une nette amélioration!!! c'est nickel, merci!!

Tite question bête pour finir , j'ai créer le formulaire frmdummy proposé dans la citation de ARO, ca marche très bien, mais je ne l'ai pas totalement invisible...
J'ai mis Affichage invisible dans les propriétés de la section détail mais apparemment ca suffit pas.
Je n'ai pas trouvé la propriété à changer pour le formulaire entier, ou puis je trouver ca?

Merci pour votre aide!

[Arkham46]

Lance une macro au démarrage dans laquelle tu ouvres ton formulaire avec mode fenêtre = masqué

a plus;

[ericain]

ok nickel!
merci beaucoup!

[leadri]

Salut,

J'ai utilisé cette solution sur la base access que je viens de développer et j'ai agréablement été surprise !!!

Merci pour toutes ces infos bien pratiques

[yoda1000]

Pt'it soucis pour moi !

Code :

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

1
2
3
4
5
6
7
 
Dans l'évènement sur ouverture du formulaire frmdummy 
(OnOpen), ouvrez un recordset
Private Sub Form_Open(Cancel As Integer)
Set rsAlwaysOpen = CurrentDb.OpenRecordset
("DummyTable")
End Sub

j'ai une erreur ! est-ce qu'il faut mette ("tbldummy") et non ("DummyTable") ?
Lorsque je fais cela, une erreur 13 apparait, j'ai donc remplacé dans le module

Public rsAlwaysOpen As Recordset
par
Public rsAlwaysOpen As DAO.Recordset

est ce que j'ai bon ???

[snejena]

Vous allez rire mais moi ... après avoir tout essayé et changé de machine ... j'ai changé de câble réseau et ça marche ... plus de lenteur du tout ...

[loufab]

Bonjour,
Souvent il faut commencer par le plus improbable mais le plus simple.

Il y a un tuto sur l'optimisation des applications ACCESS. Toutes ces ficelles y sont inventoriées.

Différence entre :

Code :

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

dim ... as Recordset

et

Code :

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

dim ... as DAO.recordset

Tu as, dans les références, la bibliothèque ADO inscrite avant DAO. Tout simplement. Du coup il faut lui spécifier laquelle tu utilises.

Cordialement,

[Serge_BDD]

Bonjour,

Je suis chargé d'accélérer le temps de réponse d'une base Access 2010 multi-utilisateurs (qui contient les formulaires et requêtes) qui en interroge une autre (là où les données sont stockées). Les 2 bases sont sur un lecteur réseau.
ARO a fait la suggestion suivante, qui me paraît très intéressante :

"- ce qui a fonctionné pour moi (mais pour internet,
faudra adapter ;-) ):
la base front end, lorsqu'elle tente d'accéder à la base
backend (tables liées à un fichier source), rencontre un
fichier lockFile (*.ldb)
Access tente alors de supprimer ce fichier, mais n'y
parvient pas (puisque quelqu'un est déjà connecté sur la
base source). Après une quinzaine de tentatives,
infructueuses, Access renvoie enfin le jeu
d'enregistrement. Pour éviter cela, voilà ce que j'ai mis
en place:
afin d'établir une connexion permanente avec la base en
backend, et donc de prévenir ce problème, créez

-un formulaire, appelons-le "frmdummy" (formulaire
stupide ;-) )
- une table "tbldummy" (avec un champ simple, n'importe
quel format, n'importe quel nom)
-dans un module standard, déclarez une variable globale
de type recordset
ex: Public rsAlwaysOpen As Recordset.
-Dans l'évènement sur ouverture du formulaire frmdummy (OnOpen), ouvrez un recordset

Code :

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

1
2
3
Private Sub Form_Open(Cancel As Integer)
Set rsAlwaysOpen = CurrentDb.OpenRecordset("DummyTable")
End Sub

-Dans l'évènement sur fermeture du formulaire frmdummy
(OnClose), fermez le recordset

Code :

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

1
2
3
4
Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

- au lancement de la db, ouvrez ce formulaire en premier, avec visible=false ce formulaire restera ouvert jusqu'à la fermeture de l'appli.

Résultat: un traitement de 5 à 10X plus rapide ..."


J'ai fait un essai, mais le résultat n'est pas flagrant, et le temps de réponse de certaines requêtes est toujours aussi long :

Est-ce du au fait que j'utilise Access 2010 et non une version antérieure à 2007 ?
J'ai tout mis dans la base interrogatrice : table, formulaire, variable globale dans un module standard, et programmation événementielle sous le formulaire ?
Ai-je eu raison, ou pas ?

En plus, je n'ai pas vraiment compris le lien entre ces modifications et l'amélioration du temps de réponse.

Si quelqu'un peut me donner des détails.

Merci

[User]

Bonjour,

Concernant ton interrogation sur Access 2010, il me semble qu'argy apporte quelques précisions dans cette discussion même si le sujet à la base concerne les formulaires en mode création:

lenteur des formulaires

Cdlt,