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.
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.
Peux tu ajouter un chronométrage avec des traces à chaque étape Vérifier si c'est l'execution qui rame ou bien la boucle de remplissage en elle même? (donc un chrono aprèsle hlitpremier) et un dans la boucle
Et fait un essai en remplaçant les tableajoute par rien, et reteste.
Tu as essayé en créant une nouvelle fenêtre, nouvelle table (en ne reprenant que le code), juste pour voir...
Dams a formulé la demande :
Salut Gilles,
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.
Peux tu ajouter un chronométrage avec des traces à chaque étape
Vérifier si c'est l'execution qui rame ou bien la boucle de remplissage
en elle même? (donc un chrono aprèsle hlitpremier) et un dans la boucle
Et fait un essai en remplaçant les tableajoute par rien, et reteste.
Tu as essayé en créant une nouvelle fenêtre, nouvelle table (en ne
reprenant que le code), juste pour voir...
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.
Peux tu ajouter un chronométrage avec des traces à chaque étape Vérifier si c'est l'execution qui rame ou bien la boucle de remplissage en elle même? (donc un chrono aprèsle hlitpremier) et un dans la boucle
Et fait un essai en remplaçant les tableajoute par rien, et reteste.
Tu as essayé en créant une nouvelle fenêtre, nouvelle table (en ne reprenant que le code), juste pour voir...
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
C'est une idée mais c'est la propriété affichageactif qu'il faut utiliser, rendre invisible un élément de l'ihm c'est déroutant pour l'utilisateur.
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
C'est une idée mais c'est la propriété affichageactif qu'il faut
utiliser, rendre invisible un élément de l'ihm c'est déroutant pour
l'utilisateur.
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
C'est une idée mais c'est la propriété affichageactif qu'il faut utiliser, rendre invisible un élément de l'ihm c'est déroutant pour l'utilisateur.
Gilles
Dams a formulé la demande :
Idem, ça ne change rien.
La remarque de Firetox me fait penser à un truc (qui serait normalement résolu par affichage actif)
Dans ta table, tu as ZERO ZERO Code dans les colonnes? T'aurais pas un truc qui se calcule à chaque affichage de colonne ou de ligne?
Parce que dans le genre qui pourri les perfs c'est top ça ;)
Dams a formulé la demande :
Idem, ça ne change rien.
La remarque de Firetox me fait penser à un truc (qui serait normalement
résolu par affichage actif)
Dans ta table, tu as ZERO ZERO Code dans les colonnes?
T'aurais pas un truc qui se calcule à chaque affichage de colonne ou de
ligne?
Parce que dans le genre qui pourri les perfs c'est top ça ;)
La remarque de Firetox me fait penser à un truc (qui serait normalement résolu par affichage actif)
Dans ta table, tu as ZERO ZERO Code dans les colonnes? T'aurais pas un truc qui se calcule à chaque affichage de colonne ou de ligne?
Parce que dans le genre qui pourri les perfs c'est top ça ;)
Dams
Re bonjour,
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 pouvai t 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 mettr e 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
Re bonjour,
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 pouvai t
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 mettr e
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é.
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 pouvai t 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 mettr e 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
Bon verdict
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
mais c'est énorme le temps que ça prend. En même temps il faut écri re 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 !
Bon verdict
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
mais c'est énorme le temps que ça prend. En même temps il faut écri re
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.
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
mais c'est énorme le temps que ça prend. En même temps il faut écri re 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
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) :
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" a écrit dans le message de news:
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.
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) :
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" <damosse31@gmail.com> a écrit dans le message de news:
a67cf62e-02af-4838-a1ab-cce4b0fb3670@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é.
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" a écrit dans le message de news:
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
Dams a formulé la demande :
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.
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
Dams a formulé la demande :
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.
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)
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.
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
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 +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
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 +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
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 +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
VPSoft
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.
Victor
"Romain PETIT" a écrit dans le message de news:
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 +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
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.
Victor
"Romain PETIT" <VoirM@Signature.fin> a écrit dans le message de news:
mn.0b8b7da3184c14b1.2248@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 +-+
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.
Victor
"Romain PETIT" a écrit dans le message de news:
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 +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Gilles
Dams a émis l'idée suivante :
Bon verdict
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
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 !
Bon courage,
si c'était pas une base clients, je t'aurais bien proposé de m'envoyer la fenêtre et l'analys, histoire d'essayer de mon côté ;)
Dams a émis l'idée suivante :
Bon verdict
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
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 !
Bon courage,
si c'était pas une base clients, je t'aurais bien proposé de m'envoyer
la fenêtre et l'analys, histoire d'essayer de mon côté ;)
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
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 !
Bon courage,
si c'était pas une base clients, je t'aurais bien proposé de m'envoyer la fenêtre et l'analys, histoire d'essayer de mon côté ;)
