Discussion :

[REDHEAD]

Bonjour,

j'ai base de données en circulation qui gère la locations de matériel.
Celle-ci comporte des formulaires avec des listeView dont le remplissage se fait via des recordsets DAO. Tout cela fonctionne à merveille que ce soit en mdb ou en mde, sous access 2003.
Par contre, si je met la même application sous runtime 2003, le temps d'accès aux formulaires, via les recordsets, est multiplié par 10 lorsque le recordset effectue une recherche sur une table qui est déjà ouverte via un formulaire ou une liste par un autre utilisateur.

Merci de vos remarques à ce sujet.

[argyronet]

Bonjour,

Dans un premier temps, créé un raccourci sur le bureau de ton PC pointant sur le MDE de ton projet avec la syntaxe suivante :

Code :

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

"C:\Program Files\%MSOffice%\MSACCESS.EXE" "C:\Ton projet\Ton appli.mde" / Runtime

Est-ce que le comportement est le même ?

Argy

%MSOffice% repésente le dossier où est installé Office...

[REDHEAD]

Bonjour Argyronet,

Merci de t'intéresser à mon problème.

J'ai effectué le test de démarrer le fichier Mde en mode runtime . C'est toujours pareil, le PC équipé d'access 2003 avec un démarrage en mode runtime est beaucoup plus rapide que ceux équipés en runtime.

Existerait-il une différence entre Access démarré en mode runtime et le runtime ?

[REDHEAD]

Pour info,

je me suis aperçu que le problème est présent uniquement lorsque un autre utilisateur est connecté à la base.

[argyronet]

Humm,

Ta base est-elle scindée en Frontale/Dorsale ?

Argy

[REDHEAD]

Oui, bien sur.

Mdb en dorsale et Mde en frontale.

[REDHEAD]

Bon, je cherche toujours...

En fait, ce sont les requêtes SQL écrites en VBA qui rament. De ce fait la DAO qui reposent sur du SQL rame aussi !

Mais alors pourquoi ! J'en sais rien du tout.

[argyronet]

Le Runtime n'est pas responsable de ça...
Il y a autre chose mais là, il faudrait analyser localement.

Questions:

1. Où est la base dorsale : Sur un seveur ou sur ton poste ?
2. Les tables sont-elles indexées ?
3. Tes requêtes ont elles ce comportement si tu es seul sur le poste Runtime au même titre que ta remarque vis à vis de cette lenteur dès qu'un utilisateur est connecté aussi...?

Argy

[REDHEAD]

Bonjour Argy,

Tu me soulage en me disant que cela ne vient pas du Runtime car cela veut dire que le problème peut être corrigé... Enfin je l'espère !

Voici les réponses à tes questions :
1) La base dorsale est située sur un serveur. J'ai également essayé sur un poste à part, pour voir si cela ne pouvait pas venir du réseau ou d'un quelconque droit d'accès. Résultat identique sur serveur ou poste.

2) Oui.

3) Oui, les l'accès aux données est lent dès qu'il y a plus d'un utilisateur. Tout seul ça marcha bien.

Entre temps, j'ai vérifié mon code dans les modules. Il manquait dans quelques formulaires une "Option explicit" par ci ou par la, mais rien n'est sorti débogage.

Je cherche encore et encore...



Merci de ton aide

Redhead

[argyronet]

Humm, il va falloir trouver la requête/routine pénalisante... ca va pas être simple mais, en fait, on va biaiser... Créé une base avec une table avec quelques dizaines de données (Les "Comptoirs" fera l'affaire si tu la scindes) et pose la sur ton serveur dans les mêmes conditions.

Créé un MDE (avec un form de démarrage) attaché à cette base au niveau des tables avec un ou deux formulaires et une ou deux requête qui te puissent te permettre d'ajouter, supprimer et mettre à jour des données dans un contexte un peu similaire à ta BDD qui pose problème et quelques routines DAO qui fasse la même chose...
Compare une utilisation locale d'une utilisation sur un poste Runtime avec un seul puis deux Users.

Est-ce que tu as un comportement identique ?

Argy

[REDHEAD]

J'ai effectué divers test comme tu me l'a conseillé. J'ai toujours le même problème.

Par contre j'ai fait un autre test intéressant. Je m'explique : Mon application tourne ou plutôt tournait sans problème depuis plus de 4 ans. C'est une application qui a évolué avec le temps. Mais à chaque fois que j'ai fait des mises à jour j'ai conservé toutes les anciennes version Mdb et Mde.

J'ai testé avec la version précédente qui date de Mars 2007 et la, ça marche nickel. Ma dernière version a commencé à être modifiée fin 2008, sauf qu'entre temps, mon Access2003 a eu des mises à jour de la part de Microsoft, notamment le pack3 d'office et d'autres correctifs. Est-ce que ce problème ne pourrait pas venir d'une mise à jour "foireuse" ?

Evidement, pour le test j'essaye sur une partie du programme qui n'a pas été modifiée entre les deux versions. Et chose encore plus étrange, si je créer une nouvelle base et que j'importe un formulaire avec du sql qui fonctionne bien, dans ma nouvelle base j'ai de nouveau ce problème de lenteur si plusieurs utilisateurs.

[argyronet]

Oui mais quand tu dis que ta version de Mars 2007 marche nickel, c'est bien sur le SP3 actuel donc, ça ne vient de ça...
Il faut que tu compares quels changement tu as mis en oeuvre depuis, notamment au niveau des références... Par exemple DAO 2.5/3.5 object library plutôt que 3.6... et que le DAO embarqué dans le Runtime est bien DAO360.DLL...

Argy

[REDHEAD]

y a du nouveau !

J'ai pris les boules et ça faisait longtemps que je voulais le faire, j'ai reformater le pc sur lequel est installé Access 2003. J'ai mis les dernières mises à jour Microsoft. Maintenant j'ai le même problème sur ce pc qu'avec ceux équipés en Runtime. Mon ancienne version fonctionne partout et la nouvelle bug sur tous les postes.
Je me dis alors que c'est peut-être tout simplement ma dernière version qui est corrompue...

Qu'en penses tu Argy ?

[REDHEAD]

j'ai trouvé !

Par contre je sais pas pourquoi !

Après avoir comparer mon ancienne et ma nouvelle version, j'ai vu que j'avais abandonné un système de messagerie qui permettait aux utilisateurs de faire apparaitre une sorte de "post-it" à l'écran d'un collègue. Cela grâce à un formulaire ouvert en mode masqué qui, via son timer, aller voir toutes les 5mn si un message était présent dans la table messages. Sauf que l'inconvenient de cela c'est que la base restait tout le temps ouverte. c'était gênant pour la re-connexion des tables liées.
En fait, je me suis rendu du compte du phénomène suivant lors d'execution de requête un peu complexe. :
Prenons le cas de deux utilisateurs A et B avec chacun une base frontale sur leur poste et une base dorsale sur le serveur.
Si A travail tout seul -> tout est ok
Si B travail tout seul -> tout est ok
Si A et B travaillent ensemble -> Requêtes fortement ralenties
Si A et B travaillent ensemble et que A a une table de la dorsale ouverte via un formulaire sur son poste (même si la table n'est pas utilisé dans une requête), les requêtes de A répondent normalement, celles de B "rament".

Comment expliquer cela ?

Argy, aurais tu une explication qui pourrait m'éclairer ?

[argyronet]

Humm, l'histoire du post-it, elle vient de mon tuto ?
Dans ce cas, perso et du fait que je sois créateur du concept, je n'ai jamais rencontré ce que tu rencontres donc, il y a(vait) un shmurtzz dans ton code.

Argy

[REDHEAD]

Bonjour Argy,

Non le "post-it" était une conception "maison" bien antérieure à ton tuto.

Mais ce que je te raconte est un constat que j'ai fait et je l'ai vérifié avec une nouvelle base vierge. En plus cela ne se produit pas uniquement sur un formulaire mais sur toute les requètes écrites en vba de la base...