Discussion :

[aimer_Delphi]

Bonjour a tous,
je veut afficher tous les donnée issu d'une procédure stockée , dans un DBGRID , mais tellement j'ai plus de 200000 lignes , l'affichage des donnée est un peut lourd
SVP y a t il un moyen d'accélérer l'affichage des donnée dans un Dbgrid ?
j'utilise Delphi 7 entreprise + Interbase 7.5 server + les composants IBX.
cordialement.

[edam]

je dirais, c'est une mauvaise idée
si c'est pour imprimer aprés; utilise une transaction en lecture seul+un TQuery

[aimer_Delphi]

je dirais, c'est une mauvaise idée
si c'est pour imprimer aprés; utilise une transaction en lecture seul+un TQuery

Merci pour ta repense edam ,
mais comment faire pour afficher les 200000 dans un DBGRID?

[ShaiLeTroll]

Faudra regarder si les composants IBX propose une gestion de packet pour qu'il ne récupère qu'une partie des données

FetchRows en ODAC et aussi en IBDAC, faudra connaitre le mécanisme utilisée pour le reproduire en IBX
PacketRecords en DBX, un TClientDataSet pourra être utiliser dans ce cas

Voir si InterBase propose un équivalent de LIMIT pour coder ta propre gestion de pagination

Regarde la propriété RecordCount dans l'aide pour le TIBQuery :

RecordCount est héritée par des ensembles de données de type requête, tel que TIBQuery. Pour les ensembles de données de type requête, RecordCount contient le nombre total d'enregistrements obtenus actuellement. Afin de déterminer RecordCount à rapporter le nombre total d'enregistrements dans un ensemble de données de type requête, appelez la méthode Last d'abord.

On peut penser qu'il y a un systéme de récupération partielle !
je crois que l'on peut affecter une limite des enregistrements récupérés à chaque paquet, Est-ce que RecordCount est affectable ???
voir si BlockReadSize est utile ?

D'ailleurs, utilse ton TIBQuery en mode UNIDIRECTIONNAL
Ajoute un TDataSetProvider et un TClientDataSet, c'est ce dernier qui tu fourniras le découpage via PacketRecords


ensuite, un etre humain normal est incapable de digérer 200 000 lignes dans une grille !

[tourlourou]

ensuite, un être humain normal est incapable de digérer 200 000 lignes dans une grille !

Livre de Poche : 33 lignes par page pour celui qui traînait sur le bureau, soit l'équivalent de plus de 6 000 pages...

[aimer_Delphi]

Livre de Poche : 33 lignes par page pour celui qui traînait sur le bureau, soit l'équivalent de plus de 6 000 pages...

Merci ShaiLeTroll , tourlourou pour la réponse ,
justement je veut afficher les données dans une DBGRID par page.

[Ph. B.]

Bonjour,

je veut afficher tous les donnée issu d'une procédure stockée , dans un DBGRID , mais tellement j'ai plus de 200000 lignes , l'affichage des donnée est un peut lourd

En echo aux intervenants précédents, quel est l'intérêt de vouloir rapatrier 200000 lignes ?
En admettant 1 seconde de lecture par ligne, l'utilisateur passera plus de 55 heures à parcourir cet ensemble !!!

SVP y a t il un moyen d'accélérer l'affichage des donnée dans un Dbgrid ?
j'utilise Delphi 7 entreprise + Interbase 7.5 server + les composants IBX.

Au préalable, il faudrait identifier l'origine des lenteurs, l'exécution de la procédure stockée ou l'envoi à la grille.
S'il s'agit de l'exécution de la procédure stockée, revoir son fonctionnement est la piste à suivre.
S'il s'agit de l'envoi à la grille, avec Interbase, une procédure stockée peut être "limitée" à la manière d'une requête select col1, ..., coln from MaProcedure where coli = vali

[edam]

tous vont me dire que c'est pas vrais,
j'utilise FB depuis 1.5, j'ai jamais voulus utiliser les procédures Stocker , seulement il y a un ans, j'ai eu l'idée de les utilisés, pour des calcul sur le serveur sur des cetaines de ligne et plus de 20 colonnes et plus de 6 jointure et j'avais crus que sa seras plus rapide, j'ai crée plus de 6 PS, après je me suis aperçu que j'ai fais une belle con-ris
il seras mieux de faire les calcule en local, delphi prend bien en charge les champs calculer, rapatrier le minime des colons, dbgrid ne fitch à peut prés que les lignes nécessaire, mais il ne faut pas exagérée sur le nombre des colonnes

[SergioMaster]

Bonjour,

tous vont me dire que c'est pas vrai,
j'utilise FB depuis 1.5, j'ai jamais voulus utiliser les procédures Stocker , seulement il y a un ans, j'ai eu l'idée de les utilisés, pour des calcul sur le serveur sur des centaines de lignes et plus de 20 colonnes et plus de 6 jointures et j'avais cru que ce serait plus rapide, j'ai crée plus de 6 PS, après je me suis aperçu que j'avais fait une belle con-ris

Tous peut être pas, en tout cas moi je dirais que cela dépend beaucoup des traitements à faire. J'ai vu des logiciels avec une utilisation intensives de procédures pas forcément utiles et d'autres sans mais en méritant quelques unes. De plus es-tu sur que tes procédures/jointures soient optimales ?

Toujours est-il que je te dirais que FB1.5 est maintenant obsolète

pour en revenir à la question initiale comme les autres je dirait qu'il est insensé* de vouloir chargé 200000 lignes dans une DBGrid la première chose à faire AMHA est de modifier la procédure afin de limiter le nombre de lignes à récupérer.
Soit selon la méthode proposée par Ph.B.

S'il s'agit de l'envoi à la grille, avec Interbase, une procédure stockée peut être "limitée" à la manière d'une requête select col1, ..., coln from MaProcedure where coli = vali

soit en ajoutant quelques paramètres d'entrées à la procédure
Je privilégierai la dernière solution qui, AMHA, réduira le temps/Espace disque coté serveur
Enfin il existe le mot clé ROWS permettant de réduire le nombre de ligne (toujours en utilisant un SELECT * FROM UNEPROCEDURE) voir ici les différentes utilisation de ROWS


Parlons du DBGrid
récupérer 200000 lignes en mémoire juste pour avoir une bonne gestion de la scrollbar verticale : je ne pense pas que cela soit nécessaire !
Tout comportement supplémentaire (couleur de cellules etc...) ajoutera encore du temps


*insensé pour plusieurs raisons : trafic réseau trop important, l'utilisateur n'a certainement pas la nécessité de tout lire et sans oublier qu'un résultat de procédure n'est pas indexé

[edam]

j'utilise FB 2.5 depuis sa sortie "je suit la mode ", j'attend FB3 final
mes PS sont optimal, car les même requêtes sont exécuter rapidement sur flamerebin ou en utlisant un composant delphi ,
dans tout les cas; la création d'une procédure et ennuyeux surtout avec les déclarations des variables, et faire attention à leur position dans la requêtes surtout après "into"