Access Lenteur Multi utilisateurs

**violaine** · 27/01/2016, 11h02

Bonjour,

Je sais que ce sujet a été abordé énormément de fois mais je ne trouve pas de solution à mon problème...
J'ai développé une base Access depuis 3 ans déjà qui fonctionnait très bien. J'avais eu quelques soucis de lenteur lors de la connexion de plusieurs utilisateurs mais après avoir suivi le super tuto de Fabrice Constans : "Guide d'optimisation de vos application Microsoft ACCESS", notamment le problème d'accès au fichier ldb, tout fonctionnait nickel!

Depuis septembre nous avons changé le serveur : passage de Windows Server 2003 à Windows Server 2012 R2
Nous avons changé aussi les ordinateurs : Windows 8.1
Et du coup les versions d'Access qui sont maintenant toutes en 2013 64 bits (avant 2007 en 32bits)

Et depuis c'est très très lent quand il y a plus d'un utilisateur ...
J'ai bien sûr revu toute ma base pour qu'elle fonctionne en 64 bits, frontale, dorsale, noms courts...
Avec un utilisateur le programme répond immédiatement mais dès qu'il y en a 2 c'est très très long... Au maximum nous sommes 5 utilisateurs pas plus.

J'ai conservé le code VBA pour le problème d'accès au fichier ldb mais ça ne change rien...
Mon fichier de données est bien sur le serveur et il fait 83 112 Ko et le fichier en acdde est copier sur chaque poste de travail et fait 26 920 Ko

Est ce que quelqu'un aurait des solutions, des pistes etc...

Merci beaucoup de toute l'aide que vous pourrez m'apporter!

**loufab** · 27/01/2016, 12h25

Bonjour,
Pas évident de donner une solution miracle.

J'ai moi même constaté des lenteurs sur W 10 avec Access 2013, lors d'un accès concurrent.

Je n'ai pas testé la procédure suivante trouvé sur le forum US de MS. Elle est donc à tester :

Je te la livre donc à titre expérimental, dis-nous si cela donne des résultats :

Reset Internet Explorer Browser

Tools > Internet Options

Click on Connections Tab

Click LAN Settings

Ensure Automatically Detect Settings is the only radio button ticked.

Click OK

Start > Type CMD

Right Click on CMD and select Run As Administrator (Windows Vista, 7 & 8)

Type or copy/past the following commands pressing enter after each one

1.netsh int tcp set heuristics disabled
2.netsh int tcp set global autotuninglevel=disabled

If you haven't already, Disable Remote Differential Compression (Many users state this speeds up file transfers and network transfer speeds).

Start > Control Panel > Programs and Features > Uninstall Program

Click on Turn Windows Features On and Off

Uncheck Remote Differential Compression

Wait for Windows to disable

Click Ok

Reboot computer and retry opening files.

Cordialement,

**violaine** · 27/01/2016, 12h34

Bonjour,

Oulala ça m'a pas l'air simple! J'ai appris toute seule à "programmer" en VBA sur Access notamment grâce aux tutos très clairs du site ainsi qu'avec les forums.
Je veux bien essayer de faire les manipulations mais est ce que tu pourrais me dire où est ce que je dois les faire exactement ?

Merci beaucoup

**violaine** · 27/01/2016, 13h07

Re bonjour,

C'est bon j'ai réussi à faire tout ce qui était écrit mais sur mon poste. Du coup est ce que je dois le faire sur tous les postes utilisateurs? Est ce que je dois le faire sur le serveur?

Autre question est ce que je dois laisser ou supprimer le code concernant le frm_ldb ?

Merci beaucoup

**loufab** · 27/01/2016, 17h27

Déjà Est-ce que tu as vu une amélioration sur ton poste lorsque d'autres utilisateurs sont connectés.
Sinon je pense qu'il faut faire la manip du CMD sur le serveur. Sachant qu'on peut revenir en arrière.

Pour le ldb, il faut tenter la chose (juste mettre en commentaire le branchement), personnellement je n'ai jamais eu besoin de l'utiliser.

Quand vous avez migré, le nouveau chemin d'attachement est-il court ou long ?

Comme tu le vois tu es cobaye comme c'est souvent le cas pour ce type de problème.

**violaine** · 27/01/2016, 17h50

Il faut bien un cobaye!

Bon j'ai fait la manipulation sur tous les postes mais pas sur le serveur et aucune amélioration... J'ai laissé le ldb et le chemin d'attachement est le même.
Je vais faire la manipulation sur le serveur et voir ce que ça donne.

Ça rame vraiment mais quand un formulaire est déjà ouvert quand il y a une zone de liste déroulante, ça prend un temps fou à s'ouvrir et à faire une sélection (il n'y a pas beaucoup de zone de liste).

Généralement c'est pour le dernier à ouvrir la base que c'est plus rapide et pour ceux connectés avant c'est la vrai galère... Même à 2 c'est l'enfer...

**violaine** · 27/01/2016, 19h14

Re,

Je ne sais pas si c'est lié mais j'ai voulu convertir mes tables en local et là j'ai une erreur "impossible de créer une relation". C'est la première fois que j'ai cette erreur. D'où peut elle venir?
Merci

**Logik64** · 28/01/2016, 09h06

Bonjour,
Je ne sais pas si le problème vient de la version 64 bits d'Access, mais personnellement je suis les conseils de Microsoft :

https://support.office.com/fr-fr/art...e-6c6f49b8d261

Cordialement.

**loufab** · 28/01/2016, 09h13

Non je ne pense pas que cela soit lié c'est plutôt un problème de fichier en lecture seule ou de droits manquant.

Sinon pour le problème :
As-tu fais un compactage de la dorsale et une décompilation de la frontale et relivré aux postes clients. ?

Peux-tu poster le nom du fichier de données et son chemin complet ?

Avec un server 64bits et multicore certains conseillent de modifier le buffer au démarrage de l'application :

Code :

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

DBEngine.SetOption dbMaxBufferSize, 65536

**violaine** · 28/01/2016, 12h47

Bonjour,

En ce qui concerne mon problème de relation, j'ai tout repris en créant une nouvelle base et en y important mes tables, requêtes, formulaires... Puis j'ai compilé, fractionné et le problème des relations n'existe plus!
Depuis c'est toujours asseez lent mais il y a quand même eu une amélioration!

le nom du fichier de données avec le chemin complet: "W:\Extravpi\Extra_be.accdb"

A quel endroit est ce que je dois mettre le code?

Encore merci de l'aide précieuse que vous m'apportez! C'est motivant

**naphta** · 28/01/2016, 13h19

Bonjour,

Lorsque l'on ouvre un frontal connecté à une base centrale, ce dernier charge en mémoire locale toutes les tables correspondantes au formulaire chargé.

Ce que j'ai fait : sur le formulaire d'accueil que des infos calculés, pas de formulaire lié à une requête ou table. Si on lance l'appli l'écran d'accueil apparait et il n'y a pas de fichier de verrou sur la base centrale créé par access.

Pour les autres formulaires lors des chargements je positionne le recordset en mode instantané puis si l'utilisateur veut faire une modification je positionne le recordset du formulaire en lecture/écriture.

Il faut en gros éviter
les listes déroulantes (ce que je fais : je met un bouton qui appelle un formulaire générique qui affiche les infos : par exemple la liste des salariés si l'on doit remplacer un nom sur une fiche.)
de solliciter les tables en lecture écriture tant que l'on peut, les formulaires de consultations mettre les tables en lecture,
fabriquer un max de requêtes et de tables temporaires en local
Les empilements de formulaires

faire un frontal allégé sans matière grasse

à bientôt

**loufab** · 28/01/2016, 13h57

En effet Naphta a fait un bon résumé des bonnes pratiques.

Le code doit être placé dans le code qui s'exécute en premier.

Pour éviter de tout reprendre comme tu l'as fait voici un lien vers mon blog pour faire une décompilation.
http://blogaccess.free.fr/?p=75

**violaine** · 28/01/2016, 14h20

Envoyé par naphta

Bonjour,

Lorsque l'on ouvre un frontal connecté à une base centrale, ce dernier charge en mémoire locale toutes les tables correspondantes au formulaire chargé.

Ce que j'ai fait : sur le formulaire d'accueil que des infos calculés, pas de formulaire lié à une requête ou table. Si on lance l'appli l'écran d'accueil apparait et il n'y a pas de fichier de verrou sur la base centrale créé par access.

Pour les autres formulaires lors des chargements je positionne le recordset en mode instantané puis si l'utilisateur veut faire une modification je positionne le recordset du formulaire en lecture/écriture.

Il faut en gros éviter
les listes déroulantes (ce que je fais : je met un bouton qui appelle un formulaire générique qui affiche les infos : par exemple la liste des salariés si l'on doit remplacer un nom sur une fiche.)
de solliciter les tables en lecture écriture tant que l'on peut, les formulaires de consultations mettre les tables en lecture,
fabriquer un max de requêtes et de tables temporaires en local
Les empilements de formulaires

faire un frontal allégé sans matière grasse

à bientôt

Bonjour,

Merci pour tous ces éléments.
J'ai essayé au maximum de suivre ces recommandations : formulaires en recordset instantané sauf ceux où il doit y avoir des modifications ; il y a très peu de liste déroulante..
Je vais regarder pour mettre certaines tables peu mises à jour en local et aussi les requêtes.

Ce qu est très frustrant c'est qu'avant tout fonctionnait très rapidement!

**violaine** · 28/01/2016, 18h48

Bonjour,

J'ai mis le code dans l'ouverture du premier formulaire.
Je vais voir ce que ça donne demain avec plusieurs utilisateurs !

Encore aujourd’hui toutes les relations de mes tables ont disparues sans que je sache pourquoi... Je vais essayer de voir ce qui se passe...

Sinon aujourd'hui tout le monde a trouvé que les lenteurs étaient beaucoup moindre!

Je vous tiens au courant

Merci beaucoup!