Lenteur remplissage de table (62000 enregistrements)
31 réponses
Dams
Bonjour,
je rencontre une lenteur =E9norme 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=E9tiques permettant =E0 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=E9lectionn=E9.
PROCEDURE RefreshClients()
// Je vide la table
TableSupprimeTout(TABLE_CLIENTS)
// Je r=E9cup=E8re la lettre s=E9lectionn=E9e dans l'onglet s=E9lectionn=E9
sLettre est une chaine =3D ONG_FILTRE[ONG_FILTRE]..Libell=E9
// Je cr=E9=E9 mon filtre sur les clients contenant la lettre s=E9lectionn=
=E9e
// sRubParcours contiendra la rubrique retourn=E9e automatiquement pour
la parcours
sRubParcours est une chaine =3D HFiltre(CLIENTS, "NOM LIKE '"+sLettre
+"%'")
// Je lit le premier client trouv=E9
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=E9sactive le filtre cr=E9=E9
HD=E9sactiveFiltre(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=E8s vous je m'y prend mal pour
remplir ma table, pourtant j'utilise des filtres pour =E9viter de
charger TOUTES les donn=E9es, ou alors c'est Windev qui est limit=E9.
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
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
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
VPSoft
"Romain PETIT" a écrit dans le message de news:
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" <VoirM@Signature.fin> a écrit dans le message de news:
mn.0bad7da3b0d0bd62.2248@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.
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
Il se trouve que Romain PETIT a formulé :
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...
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
Il se trouve que Romain PETIT a formulé :
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...
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
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...
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
VPSoft
"Romain PETIT" a écrit dans le message de news:
Il se trouve que Romain PETIT a formulé :
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)
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
"Romain PETIT" <VoirM@Signature.fin> a écrit dans le message de news:
mn.0bda7da374e67956.2248@Signature.fin...
Il se trouve que Romain PETIT a formulé :
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)
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.
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)
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
Le 1 mars 2010 à 15:03, dans <news:4b8bc93b$0$17884$, 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
Le 1 mars 2010 à 15:03, dans
<news:4b8bc93b$0$17884$ba4acef3@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)
Le 1 mars 2010 à 15:03, dans <news:4b8bc93b$0$17884$, 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
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
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 !
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
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.
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 !
Gilles
Dams a formulé ce mardi :
Salut à tous,
je confirme comme indiqué que ma rubrique NOM est bien évidemment une 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 !
Et la prochaine fois :
Oublie HFiltre, cette fonction devrait avoir disparu depuis la version 5... ;)
Dams a formulé ce mardi :
Salut à tous,
je confirme comme indiqué que ma rubrique NOM est bien évidemment une
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 !
Et la prochaine fois :
Oublie HFiltre, cette fonction devrait avoir disparu depuis la version
5... ;)
je confirme comme indiqué que ma rubrique NOM est bien évidemment une 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 !
Et la prochaine fois :
Oublie HFiltre, cette fonction devrait avoir disparu depuis la version 5... ;)
Firetox
Bonjour,
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" a écrit dans le message de news: 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
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 !
Bonjour,
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" <damosse31@gmail.com> a écrit dans le message de
news:d182bf02-b93f-4844-8ad8-c57be0304bf5@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
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.
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" a écrit dans le message de news: 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
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
"Gilles" a écrit dans le message de news: 4b8d71a4$0$23895$
Merci pour ces échanges plus que constructifs !
Et la prochaine fois :
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
"Gilles" <boulot_NOSPAM_ARETIRER@neogie.com> a écrit dans le message de
news: 4b8d71a4$0$23895$426a74cc@news.free.fr...
Merci pour ces échanges plus que constructifs !
Et la prochaine fois :
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.
"Gilles" a écrit dans le message de news: 4b8d71a4$0$23895$
Merci pour ces échanges plus que constructifs !
Et la prochaine fois :
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
Gilles
VPSoft a exprimé avec précision :
"Gilles" a écrit dans le message de news: 4b8d71a4$0$23895$
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.
Problème qu'il n'aurait pas subi sans l'utilisation de cette fonctaionnalité archaique ;)
VPSoft a exprimé avec précision :
"Gilles" <boulot_NOSPAM_ARETIRER@neogie.com> a écrit dans le message de news:
4b8d71a4$0$23895$426a74cc@news.free.fr...
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.
Problème qu'il n'aurait pas subi sans l'utilisation de cette
fonctaionnalité archaique ;)
"Gilles" a écrit dans le message de news: 4b8d71a4$0$23895$
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.
Problème qu'il n'aurait pas subi sans l'utilisation de cette fonctaionnalité archaique ;)
