Lenteur remplissage de table (62000 enregistrements)
Dams
je rencontre une lenteur énorme lors du remplissage de ma table
(environ 32 secondes) qui contient des clients, rien de plus
classique.
Mon fichier CLIENTS contient 62000 enregistrements, et je rempli ma
table par programmation. Au dessus de ma table il y a des Onglets
alphabétiques permettant à l'utilisateur de filtrer les clients (A, B,
C, D ...) chaque onglet contient une lettre donc je construit mon
filtre en fonction de l'onglet sélectionné.
PROCEDURE RefreshClients()
// Je vide la table
TableSupprimeTout(TABLE_CLIENTS)
// Je récupère la lettre sélectionnée dans l'onglet sélectionné
sLettre est une chaine = ONG_FILTRE[ONG_FILTRE]..Libellé
// Je créé mon filtre sur les clients contenant la lettre sélectionnée
// sRubParcours contiendra la rubrique retournée automatiquement pour
la parcours
sRubParcours est une chaine = HFiltre(CLIENTS, "NOM LIKE '"+sLettre
+"%'")
// Je lit le premier client trouvé
HLitPremier(CLIENTS, sRubParcours)
// Je boucle sur tous les clients et je rempli ma table
TANTQUE HTrouve(CLIENTS)
TableAjouteLigne(TABLE_CLIENTS, CLIENTS.NOM, CLIENTS.PRENOM,
CLIENTS.SOCIETE)
HLitSuivant(CLIENTS)
FIN
// Je désactive le filtre créé
HDésactiveFiltre(CLIENTS)
Le remplissage de la table dure environ 32 secondes !! Pour un simple
remplissage comme celui-ci.
Ma question est de savoir si d'après vous je m'y prend mal pour
remplir ma table, pourtant j'utilise des filtres pour éviter de
charger TOUTES les données, ou alors c'est Windev qui est limité.
D'avance merci.
Romain PETIT
> Bonjour,
Bonjour,
> Le remplissage de la table dure environ 32 secondes !! Pour un simple
> remplissage comme celui-ci.
La rubrique CLIENT est-elle une clￜ ?
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ postￜ sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Romain PETIT
> Bonjour,
Bonjour,
> Le remplissage de la table dure environ 32 secondes !! Pour un simple
> remplissage comme celui-ci.
La rubrique CLIENT.NOM est-elle une clￜ ?
Dams
Je vais essayer une requête paramétrée et je vous retourne le résultat
des performances.
Dams
changement, si ce n'est 2 secondes par rapport à l'utilisation de
HFiltre soit au final 30 secondes de chargement pour 62000 clients
dans le fichier.
J'ai procédé à une ré-indexation de mon fichier CLIENTS, ce qui n'a
rien changé aux performances.
J'ai effectué une analyse de performance et le résultat indique quele
traitement du moteur (donc Windev) a pris environ 30 secondes
(fonctions HLitPremier, HLitSuivant)
La fonction HFiltre n'a pris que quelques millisecondes
Je ne sais plus trop quoi faire de mieux !
Je viens de regarder une vidéo sur le site de Windev, qui montre un
exemple de chargement d'une table avec 15 milliards d'enregistrement
en quelques millisecondes .... même si ça concerne la version 15 et
que je suis en 14, je me demande bien comment cela est possible
sachant que pour seulement 62000 de mon côté c'est inutilisable !
Si quelqu'un veut se faire du mal un pti coup :
http://www.pcsoft-windev-webdev.com/videos15/tdfcom2009/base-de-donnees-hyperfilesql-de-15-milliards-de-lignes/base-de-donnees-hyperfilesql-de-15-milliards-de-lignes.html
Dams
initialement ma table etait en liaison sur le fichier CLIENTS (liaison
mémoire justement), c'est dû à cette lenteur que j'ai rempli la table
par programmation, pensant que ça serait plus "light" mais ça change
rien.
J'ai executé une requête avec WDSQL sur mon fichier CLIENTS et le
résultat est instantané, ce qui m'amène à penser que ce n'est pas un
problème sur mon fichier ni ma requête puisque celle-ci s'exécute
rapidement.
J'ai executé la requête suivante afin de retourner tous les clients
dont le nom commence par A, et il y en a 4136
SELECT * FROM CLIENTS WHERE NOM LIKE 'A%'
C'est le remplissage de la table qui prend énormément de temps, sauf
que d'après le code que je vous ai fourni, je ne vois pas comment je
pourrais faire plus simple, c'est le mode de chargement le plus
courant je suppose.
Concernant l'autre PC, j'ai effectué un test et c'est exactement
pareil, le chargement de la table est extrêmement long. Et sur le PC
de développement sur lequel je travail c'est une bête de course donc
j'ai ecarté le problème de performances du PC :
Windows 7
12 Go RAM Tri-Channel
CPU Intel Core I7 940
2ème PC :
Windows 7
4 Go RAM
CPU Intel Core I7 920
Je sèche complet !
Eric
<news:ddc642a8-c7d4-47c7...@c16g2000yqd.googlegroups.com>,
Dams nous disait�:
> C'est le remplissage de la table qui prend �norm�ment de temps, sauf
> que d'apr�s le code que je vous ai fourni, je ne vois pas comment je
> pourrais faire plus simple, c'est le mode de chargement le plus
> courant je suppose.
D�coche "Ascenseur proportionnel" dans le descriptif de ta table
fichier, pour voir.
--
Eric
Dams
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon
fichier CLIENTS instantanément. Je pense que le principe est le même
puisqu'il y a une table qui liste les données.
Je précise, au cas où, que ma table est située dans une fenêtre
interne. J'ai pensé que ça pouvait venir de là, mais le temps de
chargement de la table est identique à l'initialisation de ma fenêtre
interne et quand elle est déjà ouverte.
Dans mon application, j'ai une fenêtre interne également, qui contient
une table, qui elle, liste des commandes. Il y en a environ 50000 et
l'affichage est instantané, j'utilise exactement le même principe de
chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont
environ 5000 clients dans leur fichier et pour qui les performances
sont très bonnes, mais à partir de 15000 ça devient inutilisable.
Firetox
essayer de faire
Matable..visible = faux
// chargement
MAtable..visible = Vrai
le fait de mettre la table en invisible fait gagner dut temps
car l'affichage des ligne est momentaenment arreter
sous windev 12 on gagne 30 % du temps de chargement
Bon dev
@+
"Dams" <damo...@gmail.com> a �crit dans le message de
news:084d89f1-8426-46a5...@d27g2000yqf.googlegroups.com...
Idem, �a ne change rien.
J'ai ouvert mon fichier avec WDMap qui affiche le contenu de mon
fichier CLIENTS instantan�ment. Je pense que le principe est le m�me
puisqu'il y a une table qui liste les donn�es.
Je pr�cise, au cas o�, que ma table est situ�e dans une fen�tre
interne. J'ai pens� que �a pouvait venir de l�, mais le temps de
chargement de la table est identique � l'initialisation de ma fen�tre
interne et quand elle est d�j� ouverte.
Dans mon application, j'ai une fen�tre interne �galement, qui contient
une table, qui elle, liste des commandes. Il y en a environ 50000 et
l'affichage est instantan�, j'utilise exactement le m�me principe de
chargement que celui que je vous ai fourni en exemple.
J'ai des clients (clients qui utilisent mon application) , qui ont
environ 5000 clients dans leur fichier et pour qui les performances
sont tr�s bonnes, mais � partir de 15000 �a devient inutilisable.
Dams
dans mon code, j'utilise déjà la propriété ..AffichageActif (Faux
avant la boucle et Vrai après la boucle). Ceci me permet d'éviter
l'actualisation de ma table à chaque itération de ma boucle, mais cela
ne change rien du tout aux performances. C'est pas visible dans le
code que je vous ai indiqué car je l'avais viré pensant que ça pouvait
venir de là.
Le fait de rendre la table invisible durant son remplissage également
ne change rien du tout.
Gilles : Au niveau de la table je n'ai aucun code même dans
l'évènement "Affichage d'une ligne'", je n'essaye même pas d'en mettre
d'ailleurs vu les performances actuelles !!
Par contre effectivement je vais essayer de remplir une table de
clients dans une nouvelle fenêtre, autre qu'une fenêtre interne et je
vous tiens informé.
Dams
Dams
J'ai créé une nouvelle fenêtre, une nouvelle table à l'intérieur, et
un copier/coller de ma procédure RefreshClients() .... idem, je suis
donc retourné sur ma fenêtre initiale.
J'ai commenté le TableAjouteLigne() et à la place j'ai copié le nom
de mon client dans un fichier txt
fSauveTexte("C:\test\"+CLIENTS.NOM+".txt", CLIENTS.NOM)
mais c'est énorme le temps que ça prend. En même temps il faut écrire
un nombre de fichier txt énorme sur le disque aussi ... donc j'ai
abandonné.
Bon après avoir "tout essayé" pour connaitre le coupable de tout ce
temps de chargement, je crois que je vais me résigner à contacter
PCSoft en leur transmettant ma fenêtre et mon fichier CLIENTS pour
qu'ils diagnostiquent l'origine de cette lenteur.
Merci à vous tous de vos conseils et astuces !
VPSoft
Je pense qu'il y a une erreur dans la syntaxe.
Il faudrait utiliser la syntaxe suivante de hFiltre, en mettant bien une
VIRGULE entre chacun des 4 param�tres (nom du fichier, nom de la rubrique
cl�, borne d�but , borne fin) :
hFiltre (CLIENTS , ma rubriqueCl�SurLeNom , sLettre+caract(0) ,
sLettre+caract(255))
hLit premier ....
tant que pas hEndehors
.....
.....
hLitSuivant ...
fin
Ca a toujours bien march� pour moi comme cela, y compris avec les tables
Fichier.
Esp�rant avoir aid�,
Victor
"Dams" <damo...@gmail.com> a �crit dans le message de news:
a67cf62e-02af-4838...@a18g2000yqc.googlegroups.com...
Bonjour,
je rencontre une lenteur �norme lors du remplissage de ma table
(environ 32 secondes) qui contient des clients, rien de plus
classique.
Mon fichier CLIENTS contient 62000 enregistrements, et je rempli ma
table par programmation. Au dessus de ma table il y a des Onglets
alphab�tiques permettant � l'utilisateur de filtrer les clients (A, B,
C, D ...) chaque onglet contient une lettre donc je construit mon
filtre en fonction de l'onglet s�lectionn�.
PROCEDURE RefreshClients()
// Je vide la table
TableSupprimeTout(TABLE_CLIENTS)
// Je r�cup�re la lettre s�lectionn�e dans l'onglet s�lectionn�
sLettre est une chaine = ONG_FILTRE[ONG_FILTRE]..Libell�
// Je cr�� mon filtre sur les clients contenant la lettre s�lectionn�e
// sRubParcours contiendra la rubrique retourn�e automatiquement pour
la parcours
sRubParcours est une chaine = HFiltre(CLIENTS, "NOM LIKE '"+sLettre
+"%'")
// Je lit le premier client trouv�
HLitPremier(CLIENTS, sRubParcours)
// Je boucle sur tous les clients et je rempli ma table
TANTQUE HTrouve(CLIENTS)
TableAjouteLigne(TABLE_CLIENTS, CLIENTS.NOM, CLIENTS.PRENOM,
CLIENTS.SOCIETE)
HLitSuivant(CLIENTS)
FIN
// Je d�sactive le filtre cr��
HD�sactiveFiltre(CLIENTS)
Le remplissage de la table dure environ 32 secondes !! Pour un simple
remplissage comme celui-ci.
Ma question est de savoir si d'apr�s vous je m'y prend mal pour
remplir ma table, pourtant j'utilise des filtres pour �viter de
charger TOUTES les donn�es, ou alors c'est Windev qui est limit�.
D'avance merci.
JeAn-PhI
> Bonjour,
>
> je rencontre une lenteur ï¿œnorme lors du remplissage de ma table
> (environ 32 secondes) qui contient des clients, rien de plus
> classique.
>
> Mon fichier CLIENTS contient 62000 enregistrements, et je rempli ma
> table par programmation. Au dessus de ma table il y a des Onglets
> C, D ...) chaque onglet contient une lettre donc je construit mon
>
>
>
> PROCEDURE RefreshClients()
>
> // Je vide la table
> TableSupprimeTout(TABLE_CLIENTS)
>
> sLettre est une chaine = ONG_FILTRE[ONG_FILTRE]..Libellￜ
>
> // Je crￜￜ mon filtre sur les clients contenant la lettre sￜlectionnￜe
> // sRubParcours contiendra la rubrique retournï¿œe automatiquement pour
> la parcours
> sRubParcours est une chaine = HFiltre(CLIENTS, "NOM LIKE '"+sLettre
> +"%'")
>
> HLitPremier(CLIENTS, sRubParcours)
>
> // Je boucle sur tous les clients et je rempli ma table
> TANTQUE HTrouve(CLIENTS)
> TableAjouteLigne(TABLE_CLIENTS, CLIENTS.NOM, CLIENTS.PRENOM,
> CLIENTS.SOCIETE)
> HLitSuivant(CLIENTS)
> FIN
>
> HDï¿œsactiveFiltre(CLIENTS)
>
>
>
> Le remplissage de la table dure environ 32 secondes !! Pour un simple
> remplissage comme celui-ci.
>
> remplir ma table, pourtant j'utilise des filtres pour ï¿œviter de
> charger TOUTES les donnￜes, ou alors c'est Windev qui est limitￜ.
>
> D'avance merci.
est ce que cela change qq chose en remplaï¿œant TANTQUE HTrouve(CLIENTS)
par TANTQUE PAS HEnDehors(CLIENTS) et aussi HLitSuivant(CLIENTS) par
HLitSuivant(CLIENTS,sRubParcours)
--
Cordialement JeAn-PhI
Romain PETIT
> Bonjour,
Bonjour,
> Je pense qu'il y a une erreur dans la syntaxe.
> Il faudrait utiliser la syntaxe suivante de hFiltre, en mettant bien une
> VIRGULE entre chacun des 4 paramï¿œtres (nom du fichier, nom de la rubrique
> clￜ, borne dￜbut , borne fin) :
Non, la syntaxe est ￜ priori acceptￜe (et mￜme ￜ la limite d'ￜtre
conseillￜ car elle donne la meilleure clￜ) :
Mais effectivement, l'aide ne prï¿œcise pas si les conditions de
sï¿œlections peuvent se faire en SQL...
Tu es sￜr, Dams, que Hfiltre te retourne le nom de la clￜ ?
Cf aide :
Filtre construit avec une condition
<Rï¿œsultat> = HFiltre(<Nom du fichier> , <Condition de sï¿œlection>)
Dï¿œtails des paramï¿œtres
<Rï¿œsultat> : Chaï¿œne de caractï¿œres
Rubrique de parcours. Correspond :
soit ￜ la clￜ de parcours du fichier si le filtre est activￜ
soit ￜ une chaￜne vide si le filtre ne peut pas ￜtre mis en place
<Nom du fichier> : Chaï¿œne de caractï¿œres (avec ou sans guillemets)
Nom du fichier de donnï¿œes, de la vue Hyper File ou de la requï¿œte
manipulￜ.
<Condition de sï¿œlection> : Chaï¿œne de caractï¿œres (avec guillemets)
Condition de sï¿œlection pour crï¿œer le filtre (voir NOTES).
Ceci-dit, je suis comme toi et j'utilise les bonnes vieilles syntaxes ￜ
4 ou 5 param.
VPSoft
Depuis 5.5, je me limite � ce que je sais qui fonctionne parfaitement
(disons � ce que je sais bien utiliser), et je suis certain que :
- Si on sait d�j� quelle est la meilleure cl� � utiliser, vaut mieux
l'indiquer que laisser Hf le d�cider
- DANS SON CAS, si la rubrique "Nom" est bien un index, la syntaxe (NomFic,
NomRubriqueCleparNom, Borne d�but, borne Fin) avec (LitPremier et
LitSuivant) va donner un r�sultat instantan�.
- Dans la Syntaxe avec "ConditionFiltre", HF va lire TOUS les
enregistrements (entre borne d�but et fin si indiqu�es) et va tester le
contenu des rubriques indiqu�es dans "condition filtre". Ainsi, il peut se
passer 10 minutes entre 2 instructions de lecture s'il y a 1000 enregs entre
2 cas r�pondant � la condition.
Victor
"Romain PETIT" <Vo...@Signature.fin> a �crit dans le message de news:
mn.0b8b7da31...@Signature.fin...
> VPSoft a �mis l'id�e suivante :
>> Bonjour,
>
> Bonjour,
>
>> Je pense qu'il y a une erreur dans la syntaxe.
>> Il faudrait utiliser la syntaxe suivante de hFiltre, en mettant bien une
>> VIRGULE entre chacun des 4 param�tres (nom du fichier, nom de la rubrique
>> cl�, borne d�but , borne fin) :
>
>
> Non, la syntaxe est � priori accept�e (et m�me � la limite d'�tre
> conseill� car elle donne la meilleure cl�) :
> Mais effectivement, l'aide ne pr�cise pas si les conditions de s�lections
> peuvent se faire en SQL...
> Tu es s�r, Dams, que Hfiltre te retourne le nom de la cl� ?
>
> Cf aide :
> Filtre construit avec une condition
> <R�sultat> = HFiltre(<Nom du fichier> , <Condition de s�lection>)
> D�tails des param�tres
> <R�sultat> : Cha�ne de caract�res
> Rubrique de parcours. Correspond :
> soit � la cl� de parcours du fichier si le filtre est activ�
> soit � une cha�ne vide si le filtre ne peut pas �tre mis en place
> <Nom du fichier> : Cha�ne de caract�res (avec ou sans guillemets)
> Nom du fichier de donn�es, de la vue Hyper File ou de la requ�te manipul�.
> <Condition de s�lection> : Cha�ne de caract�res (avec guillemets)
> Condition de s�lection pour cr�er le filtre (voir NOTES).
>
>
> Ceci-dit, je suis comme toi et j'utilise les bonnes vieilles syntaxes � 4
> ou 5 param.
>
> A+
>
> --
> Romain PETIT
> contact : rompetit chez free fr
> +-+ post� sur Usenet avec MesNews et non depuis un forum web +-+
Romain PETIT
> re-salut !
>
> Depuis 5.5, je me limite ￜ ce que je sais qui fonctionne parfaitement (disons
> ￜ ce que je sais bien utiliser), et je suis certain que :
> - Si on sait dￜjￜ quelle est la meilleure clￜ ￜ utiliser, vaut mieux
> l'indiquer que laisser Hf le dï¿œcider
> - DANS SON CAS, si la rubrique "Nom" est bien un index, la syntaxe (NomFic,
> va donner un rￜsultat instantanￜ.
> - Dans la Syntaxe avec "ConditionFiltre", HF va lire TOUS les enregistrements
> indiquï¿œes dans "condition filtre". Ainsi, il peut se passer 10 minutes entre
> 2 instructions de lecture s'il y a 1000 enregs entre 2 cas rￜpondant ￜ la
> condition.
Je suis pleinement d'accord avec toi...
(mￜme si il n'y a pas d'erreur de syntaxe ￜ proprement parler).
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ postￜ sur Usenet avec MesNews et non depuis un forum web +-+
VPSoft
"Romain PETIT" <Vo...@Signature.fin> a �crit dans le message de news:
mn.0bad7da3b...@Signature.fin...
> VPSoft a pr�sent� l'�nonc� suivant :
>> re-salut !
>>
>> Depuis 5.5, je me limite � ce que je sais qui fonctionne parfaitement
>> (disons � ce que je sais bien utiliser), et je suis certain que :
>> - Si on sait d�j� quelle est la meilleure cl� � utiliser, vaut mieux
>> l'indiquer que laisser Hf le d�cider
>> - DANS SON CAS, si la rubrique "Nom" est bien un index, la syntaxe
>> (NomFic, NomRubriqueCleparNom, Borne d�but, borne Fin) avec (LitPremier
>> et LitSuivant) va donner un r�sultat instantan�.
>> - Dans la Syntaxe avec "ConditionFiltre", HF va lire TOUS les
>> enregistrements (entre borne d�but et fin si indiqu�es) et va tester le
>> contenu des rubriques indiqu�es dans "condition filtre". Ainsi, il peut
>> se passer 10 minutes entre 2 instructions de lecture s'il y a 1000 enregs
>> entre 2 cas r�pondant � la condition.
>
>
> Je suis pleinement d'accord avec toi...
> (m�me si il n'y a pas d'erreur de syntaxe � proprement parler).
>
> A+
>
> --
> Romain PETIT
> contact : rompetit chez free fr
> +-+ post� sur Usenet avec MesNews et non depuis un forum web +-+
> news:fr.comp.developpement.agl.windev
> http://www.mesnews.net/
> http://fr.wikipedia.org/wiki/Newsgroup
>
>
Ok pour ta remarque. J'ai l'habitude de ne pas chercher autre chose d�s que
j'ai ce qu'il me faut.
J'ai failli, comme beaucoup d'autres, abandonner les filtres, jusqu'� ce que
je comprenne le fonctionnement des 2 syntaxes que j'utilise.
Bien utilis�, avec les index qu'il faut, hFiltre est bien utile, m�me pour
les tables Fichier que beaucoup ont abandonn�, surement � cause justement
d'une mauvaise utilisation de hFiltre.
Cordialement,
Victor
Romain PETIT
> Non, la syntaxe est ￜ priori acceptￜe (et mￜme ￜ la limite d'ￜtre conseillￜ
> car elle donne la meilleure clￜ) :
D'ailleurs que donne la boucle en prenant la syntaxe HF "commence par"
(donc pas de SQL) suivante :
sRubParcours est une chaine = HFiltre(CLIENTS, "NOM [='"+sLettre+"'")
// Je lit le premier client trouvￜ
HLitPremier(CLIENTS, sRubParcours)
TANTQUE HTrouve(CLIENTS)
TableAjouteLigne(TABLE_CLIENTS, CLIENTS.NOM, CLIENTS.PRENOM,
CLIENTS.SOCIETE)
HLitSuivant(CLIENTS)
FIN
HDï¿œsactiveFiltre(CLIENTS)
Sinon, il y a aussi HFiltreCommencePar...
VPSoft
"Romain PETIT" <Vo...@Signature.fin> a �crit dans le message de news:
mn.0bda7da37...@Signature.fin...
> Il se trouve que Romain PETIT a formul� :
>> Non, la syntaxe est � priori accept�e (et m�me � la limite d'�tre
>
> D'ailleurs que donne la boucle en prenant la syntaxe HF "commence par"
> (donc pas de SQL) suivante :
>
> sRubParcours est une chaine = HFiltre(CLIENTS, "NOM [='"+sLettre+"'")
>
> HLitPremier(CLIENTS, sRubParcours)
> TANTQUE HTrouve(CLIENTS)
> TableAjouteLigne(TABLE_CLIENTS, CLIENTS.NOM, CLIENTS.PRENOM,
> CLIENTS.SOCIETE)
> HLitSuivant(CLIENTS)
> FIN
>
Moi, ce que JE CROIS, c'est que, dans la syntaxe que tu indiques, tu ne lui
indiques PAS UNE BORNE mais une "Condition de s�lection". Donc si sLettre =
"P", HF va lire (de mani�re transparente) tous les enreg depuis "A" et va
traiter � partir du premier "P", d'ou le temps d'attente. En mode Test, STOP
avant HlitPremier. F8 sur l'instruction Hlit premier prendra 1/4 d'heure
avant de passer � la ligne. C'est comme �a que je m'en suis rendu compte.
La rubrique cl� donne l'ordre, les bornes donnent les limites et, �
l'int�rieur de ces bornes, on peut peaufiner avec une condition
Je sais que �a n'est pas tr�s clair entre les param�tres optionnels et
facultatifs, c'est pour cela que j'utilise toujours la syntaxe NomFic ,
NomRubCl� , BorneMini , BorneMaxi puis �ventuellement condition si besoin.
J'attends avec impatience que Dams fasse l'essai avec :
hfiltre(clients VIRGULE Nom VIRGULE sLettre+caract(0) VIRGULE
sLettre+caract(255))
rem :caract(0) et caract(255) peuvent �tre remplac�s par les constantes
hValMin et hValMax
rem2 : moi, je mettrais hEndehors au lieu de hTrouv�
Il sera surpris du r�sultat.
Victor
Eric
<news:4b8bc93b$0$17884$ba4a...@reader.news.orange.fr>, JeAn-PhI nous
disait�:
> est ce que cela change qq chose en rempla�ant TANTQUE HTrouve(CLIENTS)
> par TANTQUE PAS HEnDehors(CLIENTS) et aussi HLitSuivant(CLIENTS) par
> HLitSuivant(CLIENTS,sRubParcours)
POUR TOUT est encore plus simple.
--
Eric
Dams
je confirme comme indiqué que ma rubrique NOM est bien évidemment une
rubrique clé (avec doublons mais clé quand même)
1. J'ai modifié mon filtre en utilisant la syntaxe avec les bornes
hValMin et hValMax
HFiltre(CLIENTS, sLettre+hValMin, sLettre+hValMax)
2. Je ne rempli plus ma table par programmation, mais en Liaison
Fichier (Mémoire)
3. Quand je change d'onglet alphabétique, j'exécute le filtre ci-
dessus et je fais un TableAffiche(TABLE_CLIENTS)
Et bien le résultat c'est que ma table se charge beaucoup plus
rapidement, de l'ordre de quelques millisecondes, et les clients se
remplissent au fur et à mesure, sans blocage.
Donc conclusion, je suppose que l'utilisation du HFiltre avec les
bornes est plus performant (merci Victor !), et remplir sa table par
programmation avec une boucle donc, c'est pas le must. Tout compte
fait, il vaut mieux utiliser la simplicité qu'offre Windev, même si je
me disais que ce n'était pas toujours la meilleure solution.
Dans tous les cas, je vais distribuer une mise à jour de mon
application avec cette optimisation, je vous ferai part des retours
qui sans doute seront positifs.
Merci pour ces échanges plus que constructifs !
Firetox
normale car il fonctionne comme une table ficier et ne charge que les
enregistrements visibles
ensuite il carhe a la demande ou des qu'on en a besoin (fleche ascensseurs,
etc...)
en fait windev charge les enregistrements visibles et rend la main
le probleme est sur le parcours de la table
faites un test
chargement de la table avec la requete (table memoire) et faites un parcours
de cette table ce parcours sera rapide car toutes les lignes sont en memoire
ensuite deuxieme test avec la table li�
le chargement est semble t il rapide mais essatez de faire un parcours de
cette table (par exemple pour chercher ou cumuler quelque chose et voyez le
temps
donc tout depend de ce qu'on veut faire
si c'est pour un affichage alors le mecanisme de la table li�e est le
meilleur mais pour une table ou ensuite vous devez faire des parcours (ce
sera long a chaque parcours)
Bon dev
@+
"Dams" <damo...@gmail.com> a �crit dans le message de
news:d182bf02-b93f-4844...@a18g2000yqc.googlegroups.com...
Salut � tous,
je confirme comme indiqu� que ma rubrique NOM est bien �videmment une
rubrique cl� (avec doublons mais cl� quand m�me)
1. J'ai modifi� mon filtre en utilisant la syntaxe avec les bornes
hValMin et hValMax
HFiltre(CLIENTS, sLettre+hValMin, sLettre+hValMax)
2. Je ne rempli plus ma table par programmation, mais en Liaison
Fichier (M�moire)
3. Quand je change d'onglet alphab�tique, j'ex�cute le filtre ci-
dessus et je fais un TableAffiche(TABLE_CLIENTS)
Et bien le r�sultat c'est que ma table se charge beaucoup plus
rapidement, de l'ordre de quelques millisecondes, et les clients se
remplissent au fur et � mesure, sans blocage.
Donc conclusion, je suppose que l'utilisation du HFiltre avec les
bornes est plus performant (merci Victor !), et remplir sa table par
programmation avec une boucle donc, c'est pas le must. Tout compte
fait, il vaut mieux utiliser la simplicit� qu'offre Windev, m�me si je
me disais que ce n'�tait pas toujours la meilleure solution.
Dans tous les cas, je vais distribuer une mise � jour de mon
application avec cette optimisation, je vous ferai part des retours
qui sans doute seront positifs.
Merci pour ces �changes plus que constructifs !
VPSoft
news: 4b8d71a4$0$23895$426a...@news.free.fr...
>> Merci pour ces �changes plus que constructifs !
>
>
> Oublie HFiltre, cette fonction devrait avoir disparu depuis la version
> 5... ;)
>
>
Bonjour,
Le demandeur a trouv� cela tr�s constructif.
Son probl�me a �t� r�gl�. Il est tr�s content du r�sultat obtenu avec la
fonction, une fois correctement utilis�e.
Cordialement,
Victor
Dams
merci pour toutes ces réponses, j'ai enfin réussi à optimiser tout
cela en :
1. Liant ma table au fichier (En mémoire) directement (Plus de
remplissage manuel)
2. Quand l'utilisateur change d'onglet alphabétique, j'utilise ta
syntaxe de HFiltre avec les bornes et effectivement je m'y retrouve à
présent !!
HFiltre(CLIENTS, NOM, sLettre+hValMin, sLettre+hValMax)
Est beaucoup plus performant que mon :
HFiltre(CLIENTS, "NOM LIKE '"+sLettre+"%'")
Bon dev !
Dams