Hello !
 
Ayant développé un logiciel basé sur Access 97 et Visual Basic 6 dans notre boite, nous nous retrouvons devant un problème assez bloquant, notamment au niveau temps d'exécution de certaines requêtes de sélection simples.
 
Je prends un exemple :
Nous avons une table "Poste" contenant 300 enregistrements et une table "Opération" en contenant 100 000.
Lorsqu'on exécute la requête "SELECT Operation.[Nom Operation], Poste.[Nom Poste] FROM Operation, Poste WHERE Operation.[Numero Poste] = Poste.[Numero Poste]", cela prends 2 bonnes secondes.
 
Alors que si la table "Opération" contient 10 000 enregistrements, c'est quasi-instantané.
 
 
Comment cela se fait-il que ce soit si lent ?
 
 
Pour info :
- mes index sont créés correctement.
- mes données dans les tables sont toutes bien déclarées
- j'utilise Access 97 (pas possible de changer facilement à cause de notre façon de programmer sous VB)
 
 
 
Avec un collègue, on pensait créer une base "archive", dans laquelle on mettrait les "anciennces" données, afin de limiter le nombre d'enregistrements et d'accélérer les procédures.
L'ennui c'est que si nos clients veulent voir et/ou récupérer ces données, cela sera hyper compliqué pour nous.
 
 
Une idée ?
On ne pourrait pas créer des sélections d'enregistrements dans une table provisoirement (genre les vues) et ensuite faire des requêtes dessus afin d'optimiser le tout ?

Salut,
Je pense que, pour commencer, il faudrait revoir la requête.
 
Avec un INNER JOIN je pense que cela devrait quand même aller légèrement plus vite.
 
Mais bon, c'est bien connu qu'Access n'est pas un foudre de guerre niveau rapidité... Peut-être juste encore une chose, des fois le mieux est l'ennemi du bien. Et si tu mets trop d'indexs sur une table Access met trop de temps à tenir à jour ses indexs par rapport à l'opération demandée. Donc des fois ça ne sert pas toujours de mettre 200 indexs. Bon, remarque cela ne concerne que les ajouts, suppression et mise à jour. Dans ton cas, le problème ne vient pas de là. Mais c'est bon à savoir.
 
Enfin, bon courage!

Son FROM comme il est actuellement, ou un INNER JOIN donnera le meme resultat. Par contre, il faut voir les index que la requete va choisir. Car il n'est pas impossible qu'il n'en prenne tout simplement pas. Normalement, un SGBD par du principe qu'il ne sert à rien de prendre un index, si 70% des enregistrement sont au moins concernés. Du coup, il va falloir un table scan. Si maintenant tu as 10x plus d'enregistrements, le temps d'execution risque d'etre lui aussi multiplié par 10.

Salut,
 
Au niveau du résultat c'est bien clair... Mais au niveau des performances? Est-ce que cela ne va pas changer?

Non, car celà se traduit de la meme maniere pour le moteur. Apres ce depend de la qualité de conception du moteur. De toute façon, le INNER JOIN est plus propre.

Merci pour vos infos.
 
Le INNER JOIN ne change rien du tout, j'ai déjà testé.
Les index, pour tout vous dire j'en ai 1 dans la table "Poste" et 2 dans la table "Element", ce qui normalement est le mini et le maxi que je puisse mettre pour que ce soit correct.
 
J'ai trouvé un moyen d'accélérer mes sélections.
En fait j'ai créé un réplica de ma base sous Access.
Comme ça je peux laisser la base sur le serveur + 1 réplica en local et lancer ensuite une synchronisation quand nécessaire.
Cela prends 2 fois + de place, mais les requetes s'exécutant en local, ça va + vite.
De plus, travailler sur un réplica semble nettement + rapide aussi puisque ma requete ci-dessus s'exécutait sur mon poste de dev en 590ms et s'exécute maintenant en 20ms !
 
M'enfin c'est de la bidouille et pas pratique à gérer...

cinoks : Je trouve le INNER JOIN illisible sur des requetes portant sur 5 ou 10 tables !
Alors que ma méthode est beaucoup plus lisible !

C'est marrant, je prefere le INNER JOIN. Ca permet de differencier les regles de jointures des conditions de selection. Avec 10 tables, ca devient ingerable de faire la distinction.  
 
Sinon, Access a horreur de fonctionner en reseau. Ce qui normal. Puisqu'il passe son temps à ecrire en physique lors de l'execution. En local, c'est tout de meme plus efficace. Par contre, ce que tu peux faire, c'est de mettre la base avec les données en reseau. Et mettre en local une coquille avec les tables liées. Du coup, les requetes s'executeront en local.
 
Penses aussi à faire une reparation/Optimisation de la base. C'est fou comme Access ce pollue lui-meme.

cinoks : Les réparations je connais bien.
Déjà ça permet de gagner des fois 100 Mo sur une base de 250 Mo et vu que je vide totalement la base pour en remplir une autre lors de chacune de mes mises à jour, tout ça se fait déjà !
 
Par contre le coup de lier les tables, je vais essayer, ce serait encore une meilleure solution !!
 
Merci :-)