un code tel que clui ci :
intTeller est entier
POUR intteller=100000 A 101000
dsCatalogus est une Source de Données
strQuery est chaîne = "SELECT * FROM CATALOGUS WHERE
IDCatalogus="+intteller
HExécuteRequêteSQL(dsCatalogus,hRequêteDéfaut,strQuery)
HLitPremier(dsCatalogus)
SI HTrouve(dsCatalogus) ET PAS HEnDehors(dsCatalogus)
Trace(intTeller+" --> gevonden")
FIN
HAnnuleDéclaration(dsCatalogus)
FIN
où avec les fonctions hlitrecherche() etc bref sans requête,
montre que la memoire (ram) utilisée par l'applicatif est en constante
augmentation au fur et à mesure du déroulement du programme.
L'appel d'une procédure locale pour la lecture de la table par la boucle n'y
change rien (ceci afin de tester la durée de vie des variables).
L'augmentation est de quelques kb dans le cas ci dessus, mais nous utilisons
ce principe pour mettre à jour plusieurs tables de plusieurs milliers de
lignes (voir *100) , et en partant de 20 MB nous arrivons à plus de 500 Mb
reservé par notre exe (selon les information du gestionnaires de tâches).
Ceci en pointant sur des fichier HF où vers une BD MS SQL2000 via OLE DB
(l'acces natif étant plus lent).
Le probléme (depuis l'AGL ou depuis l'executable) ne vient donc pas du
moteur de bases de données.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent
Le 22/06/2004, tulip a supposé :
Bonjour,
un code tel que clui ci : intTeller est entier POUR intteller0000 A 101000
dsCatalogus est une Source de Données
strQuery est chaîne = "SELECT * FROM CATALOGUS WHERE IDCatalogus="+intteller HExécuteRequêteSQL(dsCatalogus,hRequêteDéfaut,strQuery) HLitPremier(dsCatalogus) SI HTrouve(dsCatalogus) ET PAS HEnDehors(dsCatalogus) Trace(intTeller+" --> gevonden") FIN HAnnuleDéclaration(dsCatalogus)
FIN
où avec les fonctions hlitrecherche() etc bref sans requête, montre que la memoire (ram) utilisée par l'applicatif est en constante augmentation au fur et à mesure du déroulement du programme.
L'appel d'une procédure locale pour la lecture de la table par la boucle n'y change rien (ceci afin de tester la durée de vie des variables).
L'augmentation est de quelques kb dans le cas ci dessus, mais nous utilisons ce principe pour mettre à jour plusieurs tables de plusieurs milliers de lignes (voir *100) , et en partant de 20 MB nous arrivons à plus de 500 Mb reservé par notre exe (selon les information du gestionnaires de tâches). Ceci en pointant sur des fichier HF où vers une BD MS SQL2000 via OLE DB (l'acces natif étant plus lent). Le probléme (depuis l'AGL ou depuis l'executable) ne vient donc pas du moteur de bases de données.
Merci par avance de m'avoir lu et de vos éventuelles idées.
Bon code.
Stéphan
Eviter des décalarations de variable dans les boucles ( dsCatalogus est une Source de Données ) ( strQuery est chaîne ) Celà me parait evident.
Pour les requete, je n'utilise pas mais avec les vues, il faut systematiquement un ordre du genre : si hfichierexiste(dscatalogue) alors hdetruitvue(dscatalogue)
Vérifier si le hannuledeclaration ne fait qu'anuler la déclaration sans pour autant vider le résultat de la requete
un code tel que clui ci :
intTeller est entier
POUR intteller0000 A 101000
dsCatalogus est une Source de Données
strQuery est chaîne = "SELECT * FROM CATALOGUS WHERE
IDCatalogus="+intteller
HExécuteRequêteSQL(dsCatalogus,hRequêteDéfaut,strQuery)
HLitPremier(dsCatalogus)
SI HTrouve(dsCatalogus) ET PAS HEnDehors(dsCatalogus)
Trace(intTeller+" --> gevonden")
FIN
HAnnuleDéclaration(dsCatalogus)
FIN
où avec les fonctions hlitrecherche() etc bref sans requête,
montre que la memoire (ram) utilisée par l'applicatif est en constante
augmentation au fur et à mesure du déroulement du programme.
L'appel d'une procédure locale pour la lecture de la table par la boucle n'y
change rien (ceci afin de tester la durée de vie des variables).
L'augmentation est de quelques kb dans le cas ci dessus, mais nous utilisons
ce principe pour mettre à jour plusieurs tables de plusieurs milliers de
lignes (voir *100) , et en partant de 20 MB nous arrivons à plus de 500 Mb
reservé par notre exe (selon les information du gestionnaires de tâches).
Ceci en pointant sur des fichier HF où vers une BD MS SQL2000 via OLE DB
(l'acces natif étant plus lent).
Le probléme (depuis l'AGL ou depuis l'executable) ne vient donc pas du
moteur de bases de données.
Merci par avance de m'avoir lu et de vos éventuelles idées.
Bon code.
Stéphan
Eviter des décalarations de variable dans les boucles
( dsCatalogus est une Source de Données )
( strQuery est chaîne )
Celà me parait evident.
Pour les requete, je n'utilise pas mais avec les vues, il faut
systematiquement un ordre du genre :
si hfichierexiste(dscatalogue) alors hdetruitvue(dscatalogue)
Vérifier si le hannuledeclaration ne fait qu'anuler la déclaration sans
pour autant vider le résultat de la requete
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
un code tel que clui ci : intTeller est entier POUR intteller0000 A 101000
dsCatalogus est une Source de Données
strQuery est chaîne = "SELECT * FROM CATALOGUS WHERE IDCatalogus="+intteller HExécuteRequêteSQL(dsCatalogus,hRequêteDéfaut,strQuery) HLitPremier(dsCatalogus) SI HTrouve(dsCatalogus) ET PAS HEnDehors(dsCatalogus) Trace(intTeller+" --> gevonden") FIN HAnnuleDéclaration(dsCatalogus)
FIN
où avec les fonctions hlitrecherche() etc bref sans requête, montre que la memoire (ram) utilisée par l'applicatif est en constante augmentation au fur et à mesure du déroulement du programme.
L'appel d'une procédure locale pour la lecture de la table par la boucle n'y change rien (ceci afin de tester la durée de vie des variables).
L'augmentation est de quelques kb dans le cas ci dessus, mais nous utilisons ce principe pour mettre à jour plusieurs tables de plusieurs milliers de lignes (voir *100) , et en partant de 20 MB nous arrivons à plus de 500 Mb reservé par notre exe (selon les information du gestionnaires de tâches). Ceci en pointant sur des fichier HF où vers une BD MS SQL2000 via OLE DB (l'acces natif étant plus lent). Le probléme (depuis l'AGL ou depuis l'executable) ne vient donc pas du moteur de bases de données.
Merci par avance de m'avoir lu et de vos éventuelles idées.
Bon code.
Stéphan
Eviter des décalarations de variable dans les boucles ( dsCatalogus est une Source de Données ) ( strQuery est chaîne ) Celà me parait evident.
Pour les requete, je n'utilise pas mais avec les vues, il faut systematiquement un ordre du genre : si hfichierexiste(dscatalogue) alors hdetruitvue(dscatalogue)
Vérifier si le hannuledeclaration ne fait qu'anuler la déclaration sans pour autant vider le résultat de la requete
Eviter des décalarations de variable dans les boucles ( dsCatalogus est une Source de Données ) ( strQuery est chaîne ) Celà me parait evident.
Pour les requete, je n'utilise pas mais avec les vues, il faut systematiquement un ordre du genre : si hfichierexiste(dscatalogue) alors hdetruitvue(dscatalogue)
Vérifier si le hannuledeclaration ne fait qu'anuler la déclaration sans pour autant vider le résultat de la requete
Ok pour les variables c'etait pour tester la perstistance en RAM de divers variables, le probléme est que la fonction hannuledeclaration() ni libere pas de mémoire comme l'on pourrait s'y attendre. La fonction Hlitpremier incremente la RAM utilisée par le prog, mais aucune des commandes utilisées ne la fait diminuer. Regarde si lors de test avec tes vues, la RAM varie. La logique voudrait qu'elle augmente lors de la lecture des fichiers, et diminue lors de commande telle que hannuledeclaration(). Ou d'une autre que j'ignore peut être.
D'autres idées ? -- Stéphan
Bonjour, et merci de ta réponse
Eviter des décalarations de variable dans les boucles
( dsCatalogus est une Source de Données )
( strQuery est chaîne )
Celà me parait evident.
Pour les requete, je n'utilise pas mais avec les vues, il faut
systematiquement un ordre du genre :
si hfichierexiste(dscatalogue) alors hdetruitvue(dscatalogue)
Vérifier si le hannuledeclaration ne fait qu'anuler la déclaration sans
pour autant vider le résultat de la requete
Ok pour les variables c'etait pour tester la perstistance en RAM de divers
variables, le probléme est que la fonction hannuledeclaration() ni libere
pas de mémoire comme l'on pourrait s'y attendre.
La fonction Hlitpremier incremente la RAM utilisée par le prog, mais aucune
des commandes utilisées ne la fait diminuer.
Regarde si lors de test avec tes vues, la RAM varie.
La logique voudrait qu'elle augmente lors de la lecture des fichiers, et
diminue lors de commande telle que hannuledeclaration().
Ou d'une autre que j'ignore peut être.
Eviter des décalarations de variable dans les boucles ( dsCatalogus est une Source de Données ) ( strQuery est chaîne ) Celà me parait evident.
Pour les requete, je n'utilise pas mais avec les vues, il faut systematiquement un ordre du genre : si hfichierexiste(dscatalogue) alors hdetruitvue(dscatalogue)
Vérifier si le hannuledeclaration ne fait qu'anuler la déclaration sans pour autant vider le résultat de la requete
Ok pour les variables c'etait pour tester la perstistance en RAM de divers variables, le probléme est que la fonction hannuledeclaration() ni libere pas de mémoire comme l'on pourrait s'y attendre. La fonction Hlitpremier incremente la RAM utilisée par le prog, mais aucune des commandes utilisées ne la fait diminuer. Regarde si lors de test avec tes vues, la RAM varie. La logique voudrait qu'elle augmente lors de la lecture des fichiers, et diminue lors de commande telle que hannuledeclaration(). Ou d'une autre que j'ignore peut être.
L'appli se termine seule quotidiennement. Une autre appli tâche de fond très simple surveille les tâches et redémarre l'appli principale. Un service (XYNTService) surveille la 2ème appli.
Oui...
http://minilien.com/?t8sJqjxKSG
ou
http://groups.google.fr/groups?hl=fr&lr=&ie=UTF-8&threadm=mesnews.5d247d42.cb34c394.590.2191%40Signature.fin&rnum=1&prev=/groups%3Fhl%3Dfr%26lr%3D%26ie%3DUTF-8%26q%3Dtache%2Bde%2Bfond%2B%2B%2522Romain%2BPETIT%2522%2Bgroup%253Afr.comp.developpement.agl.windev%26btnG%3DRechercher
Comment l'avez vous solutionné ?
L'appli se termine seule quotidiennement.
Une autre appli tâche de fond très simple surveille les tâches et
redémarre l'appli principale.
Un service (XYNTService) surveille la 2ème appli.
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
L'appli se termine seule quotidiennement. Une autre appli tâche de fond très simple surveille les tâches et redémarre l'appli principale. Un service (XYNTService) surveille la 2ème appli.
Oui, j'ai rencontré ce phénomène en utilisant des requêtes basées sur des objets ADO (Ole db Oracle).
Comment l'avez vous solutionné ?
En téléchargeantla version 314m.(j'avais fait un dossier béton pour le st, une fenêtre et un bouton, comme ils aiment.)
A+ Adrien.
tulip a couché sur son écran :
Bonjour,
un code tel que clui ci : intTeller est entier POUR intteller0000 A 101000
dsCatalogus est une Source de Données
strQuery est chaîne = "SELECT * FROM CATALOGUS WHERE IDCatalogus="+intteller HExécuteRequêteSQL(dsCatalogus,hRequêteDéfaut,strQuery) HLitPremier(dsCatalogus) SI HTrouve(dsCatalogus) ET PAS HEnDehors(dsCatalogus) Trace(intTeller+" --> gevonden") FIN HAnnuleDéclaration(dsCatalogus)
FIN
où avec les fonctions hlitrecherche() etc bref sans requête, montre que la memoire (ram) utilisée par l'applicatif est en constante augmentation au fur et à mesure du déroulement du programme.
L'appel d'une procédure locale pour la lecture de la table par la boucle n'y change rien (ceci afin de tester la durée de vie des variables).
L'augmentation est de quelques kb dans le cas ci dessus, mais nous utilisons ce principe pour mettre à jour plusieurs tables de plusieurs milliers de lignes (voir *100) , et en partant de 20 MB nous arrivons à plus de 500 Mb reservé par notre exe (selon les information du gestionnaires de tâches). Ceci en pointant sur des fichier HF où vers une BD MS SQL2000 via OLE DB (l'acces natif étant plus lent). Le probléme (depuis l'AGL ou depuis l'executable) ne vient donc pas du moteur de bases de données.
Oui, j'ai rencontré ce phénomène en utilisant des requêtes basées sur
des objets ADO (Ole db Oracle).
Comment l'avez vous solutionné ?
En téléchargeantla version 314m.(j'avais fait un dossier béton pour le
st, une fenêtre et un bouton, comme ils aiment.)
A+
Adrien.
tulip a couché sur son écran :
Bonjour,
un code tel que clui ci :
intTeller est entier
POUR intteller0000 A 101000
dsCatalogus est une Source de Données
strQuery est chaîne = "SELECT * FROM CATALOGUS WHERE
IDCatalogus="+intteller
HExécuteRequêteSQL(dsCatalogus,hRequêteDéfaut,strQuery)
HLitPremier(dsCatalogus)
SI HTrouve(dsCatalogus) ET PAS HEnDehors(dsCatalogus)
Trace(intTeller+" --> gevonden")
FIN
HAnnuleDéclaration(dsCatalogus)
FIN
où avec les fonctions hlitrecherche() etc bref sans requête,
montre que la memoire (ram) utilisée par l'applicatif est en constante
augmentation au fur et à mesure du déroulement du programme.
L'appel d'une procédure locale pour la lecture de la table par la boucle n'y
change rien (ceci afin de tester la durée de vie des variables).
L'augmentation est de quelques kb dans le cas ci dessus, mais nous utilisons
ce principe pour mettre à jour plusieurs tables de plusieurs milliers de
lignes (voir *100) , et en partant de 20 MB nous arrivons à plus de 500 Mb
reservé par notre exe (selon les information du gestionnaires de tâches).
Ceci en pointant sur des fichier HF où vers une BD MS SQL2000 via OLE DB
(l'acces natif étant plus lent).
Le probléme (depuis l'AGL ou depuis l'executable) ne vient donc pas du
moteur de bases de données.
Oui, j'ai rencontré ce phénomène en utilisant des requêtes basées sur des objets ADO (Ole db Oracle).
Comment l'avez vous solutionné ?
En téléchargeantla version 314m.(j'avais fait un dossier béton pour le st, une fenêtre et un bouton, comme ils aiment.)
A+ Adrien.
tulip a couché sur son écran :
Bonjour,
un code tel que clui ci : intTeller est entier POUR intteller0000 A 101000
dsCatalogus est une Source de Données
strQuery est chaîne = "SELECT * FROM CATALOGUS WHERE IDCatalogus="+intteller HExécuteRequêteSQL(dsCatalogus,hRequêteDéfaut,strQuery) HLitPremier(dsCatalogus) SI HTrouve(dsCatalogus) ET PAS HEnDehors(dsCatalogus) Trace(intTeller+" --> gevonden") FIN HAnnuleDéclaration(dsCatalogus)
FIN
où avec les fonctions hlitrecherche() etc bref sans requête, montre que la memoire (ram) utilisée par l'applicatif est en constante augmentation au fur et à mesure du déroulement du programme.
L'appel d'une procédure locale pour la lecture de la table par la boucle n'y change rien (ceci afin de tester la durée de vie des variables).
L'augmentation est de quelques kb dans le cas ci dessus, mais nous utilisons ce principe pour mettre à jour plusieurs tables de plusieurs milliers de lignes (voir *100) , et en partant de 20 MB nous arrivons à plus de 500 Mb reservé par notre exe (selon les information du gestionnaires de tâches). Ceci en pointant sur des fichier HF où vers une BD MS SQL2000 via OLE DB (l'acces natif étant plus lent). Le probléme (depuis l'AGL ou depuis l'executable) ne vient donc pas du moteur de bases de données.