lenteur d'affichage de requete dans un DBGrid [Résolu]

[nico27]

Bonjour,
dans une des applications que je développe avec C++builder/Interbase, je permet à l'utilisateur de construire ses propres requetes afin d'intérroger la base lui-même. Les résultats obtenus sont souvent très important en terme de nombre d'enregistrement.

Le problème que je rencontre avec les composants IB se situe au niveau de l'affichage des résultats. En effet entre la fin de l'exécution de la requete et l'affichage des résultats il peuit se passer un temps très important (5 minutes pour 280 000 enregistrements).

Ce qui m'ennuie le plus c'est qu'avec les composant Query et le BDE c'était
beaucoup plus rapide. On régresse??

Si quelqu'un à une idée pour améliorer les temps d'affichage

Merci d'avance.

[Barbibulle]

Fais tu un FetchAll par hazard ?
si oui alors retire le
sinon
Met toi en mode Unidirectionel pour voir (attention quand tu vas activer ce mode l'affichage dans ton DBGrid va mal se faire (en fait tu pourra avancer mais plus reculer dans les enregistrements)

Code :

1
2
IBQuery.Unidirectional := true;
IBQuery.Open;

[nico27]

Je ne fais pas de fetchall. En mode unidirectionnel j'ai déjà essayé et cela
ne change rien. J'ai essayé également de faire varier le buffer de mise en mémoire du résultat (je ne me rappelle plus du nom de la proprété).

J'ai également essayé d'afficher le résultat dans un stringGrid mais c'est
toujours aussi lent.

Je pense que c'est la mise en mémoire des résultats qui est longue et lourde.

Merci quand même.

[Barbibulle]

Envoyé par nico27

Je pense que c'est la mise en mémoire des résultats qui est longue et lourde.

Non sinon en mode unidirectionnel ça serait plus rapide. Or tu dis que c'est pareil. Donc c'est la requete qui est lente.

1-Utilises tu les indexes de tes tables dans tes requêtes ?
2-Recopie une requete qui est lente dans ISQL dans IBConsole et exécute la
a/ Est elle lente aussi ?
b/ Dans la partie résultat de ISQL il y aura 2 autres onglets : PLAN et Statistics. Donne nous les résulats optenu dans ces deux onglets.

[nico27]

voilà les résultats sur un exmple de requête qui je sais doit être longue à la
base du fait du like mais bon qui a un écart flagrant entre l'execution utilisant le bde et TQuery , et l'execution utilisant les composants IB avec IBQuery

Je tiens à te préciser que la base fait 2 GB, et que la table feuillet est 80% du volume à peu près de la base en ce qui concerne les données.

Voilà si tu as une piste fais-moi signe

thanks

Plan:Statement:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
SELECT
f.numeroligne,
f.crtition,
f.ceur,
f.tvre,
f.cacem,
f.conrigine,
f.cem,
f.tm,
f.q,
f.n,
f.ntogue,
f.cdente,
f.creoit,
f.ctdoit,
f.nmpteait,
f.mep,
f.qtdepteur,
f.qtdepateur,
f.mrm,
f.qtdrmnur,
f.qtdrmdeur,
f.mepartiroit,
f.qtayantmerateur,
f.qtayantminateur,
f.mep+f.mtantdrm+f.montanroit AS total,
f.ceoeuvre,
ad.groupespte,
rub.codegr,
rub.codesooupe
FROM feuillets f
JOIN r_rubriquessacem rub
                           ON rub.coderubriquesacem = f.coderubriquesacem
                          JOIN r_ayantsdroit ad
 
                           ON ad.codeayantdroit = f.codeayantdroit
 
WHERE (1=1) AND
(f.codeediteur = '005')AND
(UPPER(f.numerocatalogue) LIKE '%786%')
ORDER BY
f.coderepartition,
f.coderubriquesacem,
f.codeediteur

PLAN SORT (JOIN (RUB NATURAL,F INDEX (IDX_RUBRIQUEEDITEURREPARTITION),AD INDEX (RDB$PRIMARY6)))

Statistics
Execution time : 00:19:50
Starting memory 17498088
curent memory 19980323
Delta memory 2482235
Number of buffer 0
Reads 350558
writes 0
plan PLAN SORT (JOIN (RUB NATURAL,F INDEX (IDX_RUBRIQUEEDITEURREPARTITION),AD INDEX (RDB$PRIMARY6)))

[Barbibulle]

Execution time : 00:19:50

20 minutes ???
C'est ennorme !

1-Peux tu donner la structure des tables surtout :
Les cles primaires,
Index,
Clés étrangères.

2- Et me donner le résultat de cette requete avec les stats :

Code :

SELECT count(*) FROM feuillets f WHERE f.codeediteur = '005';

[nico27]

He oui c'est énorme, mais ce n'est pas du à la structure de la base. De toutes façons je ne préfère pas divulguer la structure de la base entière car cela pourrait être une faute professionnelle!
D'autant plus que la base n'a pas changée depuis que l'on utilise les composants IB. Comme je l'ai dit je crois dans le premier message, je ne pense pas que cela soit l'execution de la requete qui soit longue mais plutôt
l'affichage des résultats.
Lorsque je veux quitter la fiche qui contient le DBGrid avec les résultats, il faut attendre un temps fou pour pouvoir retravailler sur la fiche appelante.

Je viens sur le forum car je ne sais plus quoi faire, car je crois avoir tout essayé mais on peut toujours oublier qqchose.
Ce problème d'affichage est tout juste soulevé dans le livre Delphi7 d'O.Dahan, il conseille d'afficher les résultats dans un TStringGrid pour que cela soit + rapide. Cela n'est pas probant.

Le nombre d'enregistrement pour l'éditeur 005 est 3 024 949

eh oui c'est pas une petite base

Voilà

[Barbibulle]

Envoyé par nico27

Le nombre d'enregistrement pour l'éditeur 005 est 3 024 949
eh oui c'est pas une petite base

Une grosse bas n'est pas un problème à partir du moment que les requetes faites soient bien ciblés...
Tu fais un Like avec deux % sur 3 millions d'enregistrements ce n'est pas un petit traitement...

Je ne demandais pas la structure de ta base mais les index, clé primaire clé etrangère des tables utilisés et eventuellement le nombre de ligne.

Sinon ce n'est pas facile d'analyser le probleme...

De plus si sous IBConsole les stats indiquent 19 minutes je ne vois pas comment tu peux espérer aller plus vite rien qu en touchant le programme client.

Ce qui peut prendre du temps sur le poste local c'est éventuellement la bufferisation en mémoire des données et donc le transfert via le réseau des données s'il y en a beaucoup. Mais je n'ai pas l'impression que se soit le cas...
Pour ca il faudrait savoir combien de ligne rammène :

Code :

SELECT count(*) FROM feuillets f WHERE (f.codeediteur = '005') AND (UPPER(f.numerocatalogue) LIKE '%786%') ;

PS: J'ai édité ta requete pour ne pas dévoiler toutes les colonnes de ta table... Comme ca y a pas de faute prof...

[Seb des Monts]

Le UPPER doit lui aussi être gourmand sur votre grand nombre de données.
Sinon, je pensais à autre chose : j'avais une lenteur avec un DBGrid.
Une fois la requête exécutée, j'effectuais un Req->RecordCount et affichais la valeur dans l'interface pour voir le nombre d'enregistrements récupérés. C'est en fait cette opération qui ralentissait beaucoup le traitement...

bon courage

[nico27]

Ton commentaire sur le Recordcount m'a fait me pencher sur le code
qui était mis juste avant l'affichage de la fiche. Et j'ai découvert la propriété Filtered=true. J'ai mis un point d'arret et j'ai tout de suite compris
que j'avais tapé dans le mille.
C'est un de mes collègue qui s'en sert beaucoup dans les applications BDE.
J'avais déjà remarqué une certaine lenteur dans une autre petite appli interne mais cela n'était pas aussi flagrant car il y avait peu d'enregistrements.

Je suis DÉSOLÉ de vous avoir fait perdre votre temps.

Merci de votre aide

CONCLUSION: NE PAS SE SERVIR DES FILTRE AVEC LES COMPOSANTS IB

A bientôt