après avoir créé un enreg dans un fichier HF (FIC1) par un Hajoute, je continue mon traitement et fais des ajouts et modifs ds d'autres fichiers.
Je suis toujours positionné sur mon enregt de FIC1 ??
A mon humble avis je pense que non il faudra le relire ultérieurement
et dans une autre page (c'est du webdev donc je dois avoir un contexte HF) je met à jour une zone dans FIC1 par un
A ce niveau il faut faire un HLitRecherche ... pour se repositionner sur FIC1 avant de faire le HModifie
en fait le HLR n'est pas necessaire. Je remonte bien mazone sur le bon egt.
FIC1.mazone="blabla" Hmodifie(FIC1)
Comment "fermer" ou "libérer" ce contexte ? J'ai fini avec cet enreg et je ne veux plus être dessus!
Là aussi je pense que le HModifie libère l'accès à l'enreg FIC1
un Hferme me semble un peu excessif.
Le HFerme ne me semble pas nécessaire avant la fin du programme
Cordialement
-- Eric Roumégou Webmaster des Wtablettes http://cerbermail.com/?qE7t4Qvilo (cliquez sur le lien ci dessus pour me contacter en privé)
Eric Demeester
dans (in) fr.comp.developpement.agl.windev, Georges Peyre ecrivait (wrote) :
Bonjour,
A ce niveau il faut faire un HLitRecherche ... pour se repositionner sur FIC1 avant de faire le HModifie > FIC1.mazone="blabla" > Hmodifie(FIC1) > > Comment "fermer" ou "libérer" ce contexte ? J'ai fini avec cet enreg et je ne > veux plus être dessus! Là aussi je pense que le HModifie libère l'accès à l'enreg FIC1
Une fois la transaction terminée, oui.
> un Hferme me semble un peu excessif. Le HFerme ne me semble pas nécessaire avant la fin du programme
Lorsque je programmais en Windev, j'avais tendance à fermer manuellement les fichiers après en avoir terminé avec les traitements les concernant, puis à les ouvrir manuellement lorsque j'avais à nouveau besoin d'y accéder.
Windev/Webdev sont sensés se débrouiller automatiquement avec les ouvertures et fermetures de fichiers HF, mais le HFerme permet dans une certaine mesure de « forcer » l'écriture des données en cache, ce qui permet d'augmenter les chances que les données aient bien été écrites dans le fichier et de préserver l'intégrité de la base si l'appli vient à planter ensuite pour une raison quelconque.
Je précise « dans une certaine mesure » parce qu'on a pas un accès direct au comportement du cache du système d'exploitation.
L'inconvénient en procédant ainsi, est que ça ralentit considérablement les transactions en accès distant, même sur de l'ADSL, je l'avais constaté en testant le partage d'une base HF classique hébergée via Samba sur un serveur FreeBSD. Windows voyait bien Samba comme un répertoire Windows sur le réseau, mais toute demande d'ouverture de fichier, de HlitRecherche ou de fermeture déclenchait des broadcast de folie entre le client et le serveur distant, ce qui rendait l'appli à peu près inexploitable.
Ca nous avait permis à l'époque de détecter les points faibles de HF dans ce type d'environnement, d'apprendre à les contourner en stockant le maximum d'informations dans des tables ou des zones mémoire et en minimisant les ordres de recherche lecture sur les fichiers distants.
A force d'optimisation, les temps de réponse avaient été divisés par 10, mais ça restait quand même limité en production.
Ca a peut-être changé avec HF C/S, et comme dans un contexte Webdev, on suppose que la base de données est « en local » sur le serveur distant, le problème est potentiellement inexistant.
-- Eric
dans (in) fr.comp.developpement.agl.windev, Georges Peyre
<g.peyre@wanadoo.fr> ecrivait (wrote) :
Bonjour,
A ce niveau il faut faire un HLitRecherche ... pour se repositionner
sur FIC1 avant de faire le HModifie
> FIC1.mazone="blabla"
> Hmodifie(FIC1)
>
> Comment "fermer" ou "libérer" ce contexte ? J'ai fini avec cet enreg et je ne
> veux plus être dessus!
Là aussi je pense que le HModifie libère l'accès à l'enreg FIC1
Une fois la transaction terminée, oui.
> un Hferme me semble un peu excessif.
Le HFerme ne me semble pas nécessaire avant la fin du programme
Lorsque je programmais en Windev, j'avais tendance à fermer manuellement
les fichiers après en avoir terminé avec les traitements les concernant,
puis à les ouvrir manuellement lorsque j'avais à nouveau besoin d'y
accéder.
Windev/Webdev sont sensés se débrouiller automatiquement avec les
ouvertures et fermetures de fichiers HF, mais le HFerme permet dans une
certaine mesure de « forcer » l'écriture des données en cache, ce qui
permet d'augmenter les chances que les données aient bien été écrites
dans le fichier et de préserver l'intégrité de la base si l'appli vient
à planter ensuite pour une raison quelconque.
Je précise « dans une certaine mesure » parce qu'on a pas un accès
direct au comportement du cache du système d'exploitation.
L'inconvénient en procédant ainsi, est que ça ralentit considérablement
les transactions en accès distant, même sur de l'ADSL, je l'avais
constaté en testant le partage d'une base HF classique hébergée via
Samba sur un serveur FreeBSD. Windows voyait bien Samba comme un
répertoire Windows sur le réseau, mais toute demande d'ouverture de
fichier, de HlitRecherche ou de fermeture déclenchait des broadcast de
folie entre le client et le serveur distant, ce qui rendait l'appli à
peu près inexploitable.
Ca nous avait permis à l'époque de détecter les points faibles de HF
dans ce type d'environnement, d'apprendre à les contourner en stockant
le maximum d'informations dans des tables ou des zones mémoire et en
minimisant les ordres de recherche lecture sur les fichiers distants.
A force d'optimisation, les temps de réponse avaient été divisés par 10,
mais ça restait quand même limité en production.
Ca a peut-être changé avec HF C/S, et comme dans un contexte Webdev, on
suppose que la base de données est « en local » sur le serveur distant,
le problème est potentiellement inexistant.
dans (in) fr.comp.developpement.agl.windev, Georges Peyre ecrivait (wrote) :
Bonjour,
A ce niveau il faut faire un HLitRecherche ... pour se repositionner sur FIC1 avant de faire le HModifie > FIC1.mazone="blabla" > Hmodifie(FIC1) > > Comment "fermer" ou "libérer" ce contexte ? J'ai fini avec cet enreg et je ne > veux plus être dessus! Là aussi je pense que le HModifie libère l'accès à l'enreg FIC1
Une fois la transaction terminée, oui.
> un Hferme me semble un peu excessif. Le HFerme ne me semble pas nécessaire avant la fin du programme
Lorsque je programmais en Windev, j'avais tendance à fermer manuellement les fichiers après en avoir terminé avec les traitements les concernant, puis à les ouvrir manuellement lorsque j'avais à nouveau besoin d'y accéder.
Windev/Webdev sont sensés se débrouiller automatiquement avec les ouvertures et fermetures de fichiers HF, mais le HFerme permet dans une certaine mesure de « forcer » l'écriture des données en cache, ce qui permet d'augmenter les chances que les données aient bien été écrites dans le fichier et de préserver l'intégrité de la base si l'appli vient à planter ensuite pour une raison quelconque.
Je précise « dans une certaine mesure » parce qu'on a pas un accès direct au comportement du cache du système d'exploitation.
L'inconvénient en procédant ainsi, est que ça ralentit considérablement les transactions en accès distant, même sur de l'ADSL, je l'avais constaté en testant le partage d'une base HF classique hébergée via Samba sur un serveur FreeBSD. Windows voyait bien Samba comme un répertoire Windows sur le réseau, mais toute demande d'ouverture de fichier, de HlitRecherche ou de fermeture déclenchait des broadcast de folie entre le client et le serveur distant, ce qui rendait l'appli à peu près inexploitable.
Ca nous avait permis à l'époque de détecter les points faibles de HF dans ce type d'environnement, d'apprendre à les contourner en stockant le maximum d'informations dans des tables ou des zones mémoire et en minimisant les ordres de recherche lecture sur les fichiers distants.
A force d'optimisation, les temps de réponse avaient été divisés par 10, mais ça restait quand même limité en production.
Ca a peut-être changé avec HF C/S, et comme dans un contexte Webdev, on suppose que la base de données est « en local » sur le serveur distant, le problème est potentiellement inexistant.
