Vu le nombre d'anonymes (au moins 2) je ne sais plus trop à qui je réponds.

Petit rappel : lors d'une transformation d'une relation 1,n - 1,1 en MLD la clé primaire de la table du coté du 1,1 passe en clé étrangère du coté 1,n. En anglais c'est PK pour Primary Key et FK pour Foreign Key. Une PK est un index unique (clé sans doublon pour WinDev), une FK un index non unique (clé avec doublon pour WinDev).

Pour vérifier le plan d'accès de la requete je fais comme d'autres, je reprends toutes les jointures dans la clause where et je regarde si les colonnes mises en jeu sont soit des PK soit des FK (dans le cas contraire je demande explication au développeur). Ensuite je regarde les clause de filtrage.

Concernant mes connaissances SGBD elles me suffisent

Si je résume :
- x secondes pour le fetch
- 32 secondes pour la fonction recherche (c'est bien de GetTypeEpreuve(False,"",Resultat_Bte.CategorieActuel) que nous parlons ?)
- 5 minutes pour les TableAffiche.

juste avec de faire votre requete vous faite
matable..visible = faux

et à la fin
matable..visible = vrai.

Pour la réponse à qui la faute c'est plus une boutade de notre ami anonyme. Personnellement je m'en fouts un peu du moment que vous trouver d'où celà vient et que vous corrigez et que vous nous dites ce qui n'allait pas.

Bonjour,

- J'ai une application qui parcours 300 000 enregistrements avec vérifications dans des fichiers liés un peu comme vous.
2 secondes pour l'affichage d'un tableau croisé statistique dans une table mémoire (20 lignes) sur un serveur Xéon 2 Ghz avec 1Go de ram (utilisation de vues).
----------------------------

Il faudrait se poser aussi les questions suivantes :
- Quelle est l'utilité d'afficher 70 000 lignes dans une table mémoire ?????
- Pourquoi ne pas utiliser des rubriques clés pour faire les tests d'égalités ?
- Pourquoi ne pas utiliser les fonctions hyperfiles Hlit... tout en utilisant des vues (Traitement beaucoup plus rapide).

P.S.: 32 secondes c'est vraiment long pour ce type de traitement.

A bientôt,

Totof

Bonjour ,

Voici les resultats suite aux modifications conseillés :

A l'origine donc sans le tableajoute cela mets 32 secondes et des poussieres en supprimant dans le SELECT la rubirques memo texte je passe de 32 a 28 secondes ce qui est deja pas mal mais trop toujours je toruve meme par rapport a ce que vous dites.

Maintenant j'ai passé les rubriques de clauses en index ( cle avec doublon) bizarrement ca me donne un resultat de 30 secondes.

Je vous rappelle juste que se sont les resultats sans tableajoute et sans filtre dans ce cas. C'est a dire que je mets pas de critere de tri.

Par contre, lorsque je met un critere de tri le resultat est quasi instantané sauf si le resultat est de 70 000 enregistrement.

Je m'explique je fais une premiere recherche sans critere de recherche donc pas de clause where sauf pour les intégrité donc le resultat est 70 000 enregistrements donc la 30 s environ sans affichage. Ensuite une recherche avec un filtre qui est une clé avec doublon mais dont le resultat est aussi 70 000 enregistrement le temps est le meme.

Mais bienentendu si la recherche donne un resultat comme 4 000 c'est instantané. Donc les index j'ai pas l'impression que ca aide ou tres peu pour les memos ca aide un peu aussi c'est sur.

Aprés ca je vois pas comment je pourrais mieux ameliorer le mic-mac

Vous remerciant

Plouf , je suis tombé de ma chaise
je croyais que c'était 32s avec filtre
Vous voulez ramener 70000 enr. en instantané par une requête ,
mais excusez-moi , c'est n'importe quoi !
et de surcroit remplir une table avec
Quelque soit l'outil cela sera pareil!
Restons raisonables.
je pense que votre approche n'est pas bonne du tout.
et que le problème est au niveau conceptuel.

Je comprends que le serveur sature le réseau !!!
Là je ne sais pas quoi , vous dire ...


JYM

Bonjour,

Non il s'agit bien de 32 secondes sans filtre.

Le probléme est que memes avec filtre ca peut me ramener 70 000 enregistrements.

Je supposons que je mets 10 filtres et que le resultat c'est 70 000 enregistrements ???

Ca va de soit que avec filtre quand le resultat et de 0 a 7000 peut etre ou 20 000 j'en sais rien c du quasi instantanée.

Le probléme est que certain resultat sont de 70 000 enregistrements alors je dis pas que au final c'est pour afficher dans une table mais pour faire des stats...

Il fallait le dire plus tôt,

Première solution la meilleure selon moi,
Créer une ou des tables statistiques dans votre base
alimentée et calculée chaque jour, ou a une clôture fin de mois.
Faire une recherche sur le site , le sujet des stats et solutions à déjà été traité.
Sinon

autre solution :
Ne pas utiliser les requetes , mais un parcours séquentiel,
avec hlitpremier,hlisuivant...
mais le problème de lenteur sera surement encore présent.

JYM

Pour l'anonyme qui ammène des remarques sur les posts sans apporter de proposition, j'aimerais une explication lorsqu'il dit qu'il n'est pas nécessaire de mettre des index dans un where (évite de reprendre le cas classique du booléen où il est évident qu'un index ne sert pas à grand chose).

Pour l'anonyme qui est à l'origine du thread. Il est très difficile de t'apporter une aide constructive si tu apportes les infos par morceau, car entre le premier post et le dernier, le besoin n'est plus le même mis à part le problème de lenteur. La méthode proposée par Emmanuel, et d'isoler le point de ralentissement est bonne, maintenant si tu modifies ta requête entre le moment où on rédige une réponse, et que tu ne réponds pas aux questions on peut rester longtemps sur le problème sans y apporter de solution.

A titre d'anectdote, dans une appli, lorsque je coupais toutes les connexions réseaux le temps de chargement de la première fenêtre prenait de l'ordre de 30 secondes, parcontre en fonctionnement en C/S (serveur+client), l'affichage de la fenêtre est immédiat. Je suis tout de suite partie sur un problème réseau, le maitre étant sous Samba, reconfiguration des DNS primaire et secondaire....Configuration du moteur de la base en lui demandant de ne pas faire de résolution de nom etc... Toujours le même problème.
Jusqu'au moment, où j'ai décidé de revoir mon code en pas à pas, et là j'ai découvert qu'au fond d'une classe j'avais plusieurs icréepolice qui totalisaient les 30 secondes d'attentes (d'où l'importance du debug et d'isoler les temps)

Toutefois j'arrêterais ici, mais une alternantive pour les statistiques et qui peut être efficace sur une base C/S, est de passer par des tables temporaires (sur le serveur) qui sont alimentées uniquement par des commandes SQL. Celà évite des transferts de donnée entre le serveur et le client (seul la commande SQL circule).