 1 membre
Connectés : ( personne )
 - La Charte du Forum - Forum
 - Questions générale
 Sujet n° 481 |
REDUCTION DU TEMPS DE TRAITEMENT |
le 03/03/2011 : 16:45
par Lendcap
visiteur
|
Bonjour Pierre,J'ai une base de donnée dont toutes les requêtes sont complètement ecrites en SQL et cachées derière les formulaires. J'ai pour la circonstance crée les tables d'archivage pour loger les données de ces requêtes. Tout fonctionne très bien sauf le temps de traitement sur les postes clients qui me paraît trop long.Cette lenteur est elle due à ces requêtes?Par ailleurs, certaines boites de dialogues, derières lesquelles j'utilise l'instruction If Dlookup .............., s'execute aussi avec une très grosse lenteur sur les postes clients. Aquoi cela peut il être dû ?Nb: nous fonctionnons normalement avec un reseau filaire de 4 Postes.Merci pour vos reponses judicieuses. |
|  
|
Réponse n° 1
--------
le 05/03/2011 : 15:17
par 3Stone
Administrateur
|
Bonjour,
De manière générale, transformer un pousse-pousse en voiture de course n'est pas évident 
Quelques pistes:
Pour les requêtes intégrées dans une chaîne d'un module du formulaire, elles sont un peu plus lentes, effectivement. C'est parce que, contrairement à une requête enregistrée, elles ne sont pas (encore) compilées.
Mais, ce différence est minime et ne se concerne que le temps nécessaire à la compilation. A l'exécution, il n'y a plus de différence. On peut donc dire qu'elle à juste un retard au démarrage, ce qui ne doit pas faire une différence importante.
Par contre, si tu crées une requête du style :
"Select * From T_Voitures Where Couleur='rouge'" il y a intérêt à ce que le champ Couleur soit un champ indexé!
Pour les fonctions de domaine, même règle...
Il faut éviter d'utiliser un DCount(), DMax() ou Dlookup() dans une grosse requête... la fonction doit ouvrir et refermer un recordset à chaque enregistrement.
Même remarque pour les critères d'une fonction de domaine que pour les requêtes: il ont intérêt à être indexé si la table est un peu grosse.
Il faut également veiller à réduire au maximum le transfert des données sur le réseau.
Ne jamais créer une requête "généraliste" sur laquelle serait basé une ou plusieurs autres requêtes. Pour le traitement, Accèss doit ramener tous les enregsitrements de la requête "généraliste" 
Si l'on considère que beaucoup de base ne sont pas construite de façon non idéale (voir mal constuite) il ne faut pas chercher loin les problèmes qui apparaissent lorsque la base est distante et à plusieurs utilisateurs.
De façon générale, une table "étroite" (peu de champs) de 100.000 enregistrements, est plus performante qu'une table très large (comme un tableau Excel) avec 1000 enregistrements.
Se rappeler que de chercher une valeur dans un index de 100.000 items est instantané, alors que traverser toute une table de 1000 enregistrements contenant un valeur tel que "*oug*" prends un certain temps, pour ne pas dire un temps certain.
Pour finir... il existe une "astuce" qui permet parfois d'améliorer le temps de réponse d'une base distante. Cela consiste à créer une petit table (quelconque), de créer un petit formulaire caché dans la base frontale et qui aura cette table comme source.
On ouvrira ce formulaire en tout premier lieu et on le gardera ouvert (et caché) jusqu'à la fermeture de la base.
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 2
--------
le 07/03/2011 : 17:58
par Lendcap
visiteur
|
Bonjour,
Merci Pierre
J'essayerai de prendre ce que ma comprehension me permet.
Merci pour tout.
Lendcap |
|
|
|
 sujet actif
sujet clos
 Important!
 Nouveau message -
 Rectifier message
 Clôturer sujet
 Remonter
|
© 2004-2013 
