Discussion :

[jupierre]

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]

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]

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]

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]

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]

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]

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