lenteur dans les deplacements [Résolu]

jupierre · 16/01/2007, 17h55

bonjour,
j'utilise firebird 1.5, avec delphi 7 j'utilise les composants IB experts.

je souhaite me deplacer pour trouver un enregistrement rapidement. rien de fracassant donc !
la méthode locate de delphi semble la mieux appropriée.
mais c'est tres lent ! genre 4 secondes pour atteindre 2500 enregistrement plus loin ! en plus je suis en test local, meme pas de reseau !
ma recherche se fait sur une clef primaire certes en format VARCHAR et pas numerique mais bon une clef quand meme ! j'ai desactivé les tables details en pensant que ca ralentissait le changement d'enregistrement de ma table maitre mais bof, pas mieux.
faut il eviter les clefs en varchar ? comment booster l'affaire ?
merci a vous et bonne année 2007

JustMe · 16/01/2007, 19h39

La plus part des SGBDR sont unidirectionnel qui veux dire qu'il ne sont pas conçu pour la navigation (déplacement) beaucoup d'objets accèdent à une base FireBird/InterBase et mettent en cache les données recceuilis à partir du serverur, reste à choisir les objets qui sont rapide à ton cas de figure.
Mais à mon avis les traitements qu'on doit effectuer sur un ensemble important de données dois se passer sur ton Serveur SQL à l'aide de procedure stockées ça t'évitera bien des problèmes.
les composants IB experts tu veux dire IBeXpress?

jupierre · 17/01/2007, 09h41

ibx en effet, désolé.
coté composant, j'utilise les tibdataset de ibx donc.
je sais que c'est moins rapide qu'un Tibsql qui est unidirectionnel, mais avec un tibdataset c'est de tres loin + facile pour devellopper un masque de saisie !

lorsque je cherche a me rendre sur un enregistrement, par exemple la fiche n° 4.123, je fais donc un locate sur ce champ "fiche".
je peux peut etre essayer de forcer le tibdaset en unidirectionnel lors de la recherche ? ou vaut il mieux utiliser les proriete bufferchunks ? ou les deux ?
j'ai lu avec sagesse les recommandations d olivier Dahan mais la mise en oeuvre est plus complexe...

merci

Cl@udius · 17/01/2007, 09h52

Salut

Est-ce que tu as un évèmenent BeforeScroll et/ou AfterScroll d'implémenté.
Cela pourrait expliquer la lenteur du locate !

@+ Claudius

jupierre · 17/01/2007, 10h13

J'ai en effet un afterscroll sur ma table maitre, ca me met a jour la table details.
j'utilise la fonction disablecontrol sur ma table maitre et sur ma table details, cela est censé desactiver la mise a jour des control données quand je me deplace dasn les enregistrements.

j'ai testé en enlevant l'afterscroll afin de ne pas avoir de soucis avec la table details. mais ca reste tres lent.

ma recherche se fait sur la clef primaire, en format varchar(6). ai je interet a la changer en var(6) ? de plus cette clef a un index croissant? ai je interet a ajouter un nouvel index decroissant dans firebird ?

je vais deja essayer de force mon dataset en unidirectionnel lors d'une recherche

merci en tous cas, meme vos reponses sur des choses que j'ai deja testé donne de nouvelle pistes d'amelioration !

JustMe · 17/01/2007, 18h54

Un moment ne désespère pas trés vite on est là pour s'entraider.
Voilà ce que je te conseil évite de faire des recherche avec Locate.
Fait ta recherche en SQL même si ça va te prendre un peut de temps à l'implémenter mais il n'y a pas meilleur avec un petit where tu auras au maximum 1/100 seconde pour trouver un enregistrement si tu le cherche avec sa clé primaire. Tu n'aura pas à te soucier de tes scroll ni de la quantité de données dans ta table.

makowski · 17/01/2007, 19h48

Citation:

ma recherche se fait sur la clef primaire, en format varchar(6). ai je interet a la changer en var(6) ? de plus cette clef a un index croissant? ai je interet a ajouter un nouvel index decroissant dans firebird ?

et alors, cela n'a aucun sens
une recherche avec la clé primaire sur un select oui, mais une fois ton select fait et ton dataset rempli cela n'a aucun effet, tu travaille avec les données dans ton dataset en faisant certainement des fetch et la bonjour le traffic réseau
si tu veux travailler comme cela (qui n'est que rarement la bonne solution) utilise un composant qui met les données en mémoire, du genre memdataset
sinon suit les conseils de JustMe
tu ne travailles pas avec une base de données fichier (dbase, paradox) mais avec un serveur sql, cela n'a rien à voir

16/01/2007, 17h55	#1
jupierre Membre à l'essai Inscription : septembre 2002 Messages : 49 Détails du profil Informations forums : Inscription : septembre 2002 Messages : 49 Points : 23 Points : 23	lenteur dans les deplacements bonjour, j'utilise firebird 1.5, avec delphi 7 j'utilise les composants IB experts. je souhaite me deplacer pour trouver un enregistrement rapidement. rien de fracassant donc ! la méthode locate de delphi semble la mieux appropriée. mais c'est tres lent ! genre 4 secondes pour atteindre 2500 enregistrement plus loin ! en plus je suis en test local, meme pas de reseau ! ma recherche se fait sur une clef primaire certes en format VARCHAR et pas numerique mais bon une clef quand meme ! j'ai desactivé les tables details en pensant que ca ralentissait le changement d'enregistrement de ma table maitre mais bof, pas mieux. faut il eviter les clefs en varchar ? comment booster l'affaire ? merci a vous et bonne année 2007
	00

16/01/2007, 19h39	#2
JustMe Membre éprouvé Inscription : juillet 2002 Messages : 432 Détails du profil Informations forums : Inscription : juillet 2002 Messages : 432 Points : 441 Points : 441	La plus part des SGBDR sont unidirectionnel qui veux dire qu'il ne sont pas conçu pour la navigation (déplacement) beaucoup d'objets accèdent à une base FireBird/InterBase et mettent en cache les données recceuilis à partir du serverur, reste à choisir les objets qui sont rapide à ton cas de figure. Mais à mon avis les traitements qu'on doit effectuer sur un ensemble important de données dois se passer sur ton Serveur SQL à l'aide de procedure stockées ça t'évitera bien des problèmes. les composants IB experts tu veux dire IBeXpress? __________________ <On fait la science avec des faits, comme on fait une maison avec des pierres : mais une accumulation de faits n'est pas plus une science qu'un tas de pierres n'est une maison> Poincaré http://www.mobile-tactile.com/
	00

17/01/2007, 09h52	#4
Cl@udius Modérateur Claude Renouleaud Développeur informatique Inscription : février 2006 Messages : 4 758 Détails du profil Informations personnelles : Nom : Claude Renouleaud Âge : 49 Localisation : France, Hautes Pyrénées (Midi Pyrénées) Informations professionnelles : Activité : Développeur informatique Informations forums : Inscription : février 2006 Messages : 4 758 Points : 6 779 Points : 6 779	Salut Est-ce que tu as un évèmenent BeforeScroll et/ou AfterScroll d'implémenté. Cela pourrait expliquer la lenteur du locate ! @+ Claudius __________________ A la question technique que par MP/MV tu formuleras, la réponse aux oubliettes finira.
	00

17/01/2007, 18h54	#6
JustMe Membre éprouvé Inscription : juillet 2002 Messages : 432 Détails du profil Informations forums : Inscription : juillet 2002 Messages : 432 Points : 441 Points : 441	Un moment ne désespère pas trés vite on est là pour s'entraider. Voilà ce que je te conseil évite de faire des recherche avec Locate. Fait ta recherche en SQL même si ça va te prendre un peut de temps à l'implémenter mais il n'y a pas meilleur avec un petit where tu auras au maximum 1/100 seconde pour trouver un enregistrement si tu le cherche avec sa clé primaire. Tu n'aura pas à te soucier de tes scroll ni de la quantité de données dans ta table. __________________ <On fait la science avec des faits, comme on fait une maison avec des pierres : mais une accumulation de faits n'est pas plus une science qu'un tas de pierres n'est une maison> Poincaré http://www.mobile-tactile.com/
	00

17/01/2007, 09h41	#3
jupierre Membre à l'essai Inscription : septembre 2002 Messages : 49 Détails du profil Informations forums : Inscription : septembre 2002 Messages : 49 Points : 23 Points : 23	ibx en effet, désolé. coté composant, j'utilise les tibdataset de ibx donc. je sais que c'est moins rapide qu'un Tibsql qui est unidirectionnel, mais avec un tibdataset c'est de tres loin + facile pour devellopper un masque de saisie ! lorsque je cherche a me rendre sur un enregistrement, par exemple la fiche n° 4.123, je fais donc un locate sur ce champ "fiche". je peux peut etre essayer de forcer le tibdaset en unidirectionnel lors de la recherche ? ou vaut il mieux utiliser les proriete bufferchunks ? ou les deux ? j'ai lu avec sagesse les recommandations d olivier Dahan mais la mise en oeuvre est plus complexe... merci
	00

17/01/2007, 10h13	#5
jupierre Membre à l'essai Inscription : septembre 2002 Messages : 49 Détails du profil Informations forums : Inscription : septembre 2002 Messages : 49 Points : 23 Points : 23	J'ai en effet un afterscroll sur ma table maitre, ca me met a jour la table details. j'utilise la fonction disablecontrol sur ma table maitre et sur ma table details, cela est censé desactiver la mise a jour des control données quand je me deplace dasn les enregistrements. j'ai testé en enlevant l'afterscroll afin de ne pas avoir de soucis avec la table details. mais ca reste tres lent. ma recherche se fait sur la clef primaire, en format varchar(6). ai je interet a la changer en var(6) ? de plus cette clef a un index croissant? ai je interet a ajouter un nouvel index decroissant dans firebird ? je vais deja essayer de force mon dataset en unidirectionnel lors d'une recherche merci en tous cas, meme vos reponses sur des choses que j'ai deja testé donne de nouvelle pistes d'amelioration !
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email