Access sature l'UC
Résolu/Fermé
Fly50
-
7 août 2007 à 16:51
fausty66 Messages postés 54 Date d'inscription mardi 7 août 2007 Statut Membre Dernière intervention 9 août 2007 - 7 août 2007 à 17:17
fausty66 Messages postés 54 Date d'inscription mardi 7 août 2007 Statut Membre Dernière intervention 9 août 2007 - 7 août 2007 à 17:17
A voir également:
- Access sature l'UC
- Compte gmail saturé - Guide
- Stockage ipad saturé - Guide
- Espace de stockage bientôt saturé - Guide
- Access appdata - Guide
- Avis stream access ✓ - Forum Virus
2 réponses
fausty66
Messages postés
54
Date d'inscription
mardi 7 août 2007
Statut
Membre
Dernière intervention
9 août 2007
7
7 août 2007 à 16:56
7 août 2007 à 16:56
bonjour, a toi de jouer
http://access.seneque.free.fr/optimisation.htm
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
<https://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 ...
http://access.seneque.free.fr/optimisation.htm
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
<https://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 ...
noob_linux
Messages postés
805
Date d'inscription
lundi 11 octobre 2004
Statut
Membre
Dernière intervention
4 mars 2010
121
7 août 2007 à 16:54
7 août 2007 à 16:54
pas de risque avec les MAJ de win// par contre quelle est ta config matérielle ? CPU / RAM ?
fausty66
Messages postés
54
Date d'inscription
mardi 7 août 2007
Statut
Membre
Dernière intervention
9 août 2007
7
>
Fly50
7 août 2007 à 17:17
7 août 2007 à 17:17
Desole le lien est mort ,par contre avec XP 256 MO c'est trés faible ,recommandé minimum 512
