PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV Mobile 26 → persistance de données HFSQL
persistance de données HFSQL
Débuté par Pucpood, 04 nov. 2021 16:36 - 30 réponses
Membre enregistré
73 messages
Posté le 04 novembre 2021 - 16:36
Bonjour,

Je suis confronté à un problème de 'persistance de données' dans le cadre de la manipulation de fichiers HFSQL classiques.
J'importe un fichier FIC par ftp, je l'ouvre et y fait une modif de l'enregistrement XXX sans problème.
Je ferme et je supprime ce fichier sans en faire la moindre sauvegarde.
Je l'importe à nouveau depuis le ftp (sans sortir de l'appli) et je contrôle structure, index, bref, tout ce que je peux contrôler.
Quand je consulte à nouveau l'enregistrement XXX, je devrais trouver les données initiales ... et bien non, j'y trouve la modif que j'ai faite avant la suppression !

J'ai vérifié que je tapais bien toujours bien dans le même dossier.
Lorsque j'ouvre à la main le fichier que je viens de réimporter, l'index est corrompu, je dois réindexer.
Si je sors complètement de l'appli après avoir réimporté, là les données sont correctes.
- Quelqu'un a-t-il déjà eu ce type de comportement ?
- Y aurait-il un cache qui se vide quand on sort de l'appli et sur lequel il faudrait agir ?

Merci d'avoir pris la peine de me lire.
Membre enregistré
1 825 messages
Posté le 04 novembre 2021 - 17:32
Salut @Pucpood,
Est ce que tu fais un HFermeConnexion avant la supression du fichier ?
Membre enregistré
73 messages
Posté le 05 novembre 2021 - 10:06
Bonjour Popoy,

Il s'agit d'une base locale HFSQL classique. Je n'ai pas de connexion à fermer. Par contre, je fais bien un HFerme du fichier concerné. Par ailleurs, j'ai contrôlé que je ne travaillais pas sur le mauvais fichier physique : aucun risque, il n'y en a qu'1 dans l'arborescence.
Je suis allé plus loin, je réindexe systématiquement le fichier : toujours le même résultat. Je dois sortir de l'appli et la relancer pour voir les bonnes données.

Je vais quand-même aller voir dans les dossiers 'officiels' de l'appli (Android/Data...)............ Juste trouvé dans le dossier Cache des fichiers HFSQL de 0 octets.
Membre enregistré
1 825 messages
Posté le 05 novembre 2021 - 11:00
Contrairement à ce que tu crois il y a toujours une connexion à la base
Dans wm c'est dans les paramètres de l'analyse
C'est un peu le problème avec pcsoft car beaucoup de choses se font automatiquement
Or parfois il est préférable de les faire manuellement
Membre enregistré
73 messages
Posté le 05 novembre 2021 - 11:34
Je peux aisément admettre qu'il y a une connexion, mais dans ce cas elle doit avoir un nom que je n'ai pas trouvé, même dans la description de mon analyse. Sans ce nom, impossible d'utiliser HFermeConnexion.
J'ai essayé avec le nom de l'analyse, mais j'ai eu droit à une erreur fatale ... fatalement !
Membre enregistré
1 825 messages
Posté le 05 novembre 2021 - 16:26
Dans l'analyse
Clic droit > Connexions
suivant > suivant
Le nom de la connexion est alors affiché



Membre enregistré
1 825 messages
Posté le 05 novembre 2021 - 16:29



erreur d'image et imposiible d'editer le message precedent
Membre enregistré
73 messages
Posté le 05 novembre 2021 - 17:09
En fait, tu la crées explicitement au lieu de laisser faire WM. A tester. En parallèle, j'ai fait une demande au ST.
Merci à toi.
Membre enregistré
1 825 messages
Posté le 05 novembre 2021 - 18:31
Non je ne l'ai pas créer
C'est la seule façon que j'ai trouvé pour récupérer le nom de la connexion
Mais en effet, je suis curieux de savoir si il existe une autre méthode
Membre enregistré
73 messages
Posté le 09 novembre 2021 - 16:17
Bonjour du jour !

J'ai exploré la piste de Popoy, mais il ne semble pas y avoir de connexion locale à fermer. Le 'MaConnexion1' qui m'est proposé également s'applique à une nouvelle définition de connexion qu'on voudrait faire et non à celle faite implicitement par Windev. Dois-je comprendre Popoy que tu travailles toujours avec des connexions 'explicites' ?
Toujours pas de réponse PC Soft à ce jour.
Par contre j'ai remarqué un autre effet associé : des problèmes d'index. Ça pourrait bien être la clé de l'énigme. Mais je recrée déjà tous les index systématiquement. Que se passe-t-il de plus au redémarrage de l'appli pour que ce soit plus efficace ?

Autrement dit : avez-vous déjà eu des problèmes de régénération des index avec Windev Mobile (Androïd) ?
Membre enregistré
1 825 messages
Posté le 09 novembre 2021 - 18:53
Franchement je ne sais pas
Comment fait pcsoft pour ce connecter à sa base sans connexion
Je suis curieux de la réponse de pcsoft
Pour les index, personnellement je n'ai pas eu de soucis
Membre enregistré
73 messages
Posté le 18 novembre 2021 - 15:44
Bonjour,
Un petit Up au cas où ça parlerait à quelqu'un d'autre. J'ai continué mes essais à grands coups de HFerme, fSupprime, HSupprimeTout etc. Rien n'y fait ! J'ai aussi re-vérifié que je travaillais bien dans les bons dossiers. Un truc de fous.
Le premier retour de PC Soft (au bout de 10 jours) me demande une appli pour démontrer le problème. J'en ai fait une dans laquelle ... tout fonctionne impeccablement malheureusement ! Je me suis même fendu de 2 versions : WM25 et WM26.

Tiens une idée : est-ce qu'on peut détacher un fichier logique de tout fichier physique ?
Membre enregistré
73 messages
Posté le 18 novembre 2021 - 15:45
Ah oui, autre chose : j'ai 30000 enregistrements dans ma table, ça peut changer quelque-chose ?
Posté le 18 novembre 2021 - 16:36
bon...
tu dis que tu as tout vérifié, c'est bien... MAIS, si tu nous montres ton code, on va pouvoir vérifier aussi et peut être voir ce que tu ne vois pas

Sans ca, en théorie, tout ce que tu fais devrais fonctionner.
Membre enregistré
73 messages
Posté le 19 novembre 2021 - 09:15
C'est juste et ça m'oblige a bien refaire mes contrôles. Voici le code que j'ai hyper simplifié et avec lequel j'ai toujours le problème.
Note : je suis sûr de ce qu'il y a dans le fichier situé sur le serveur

Procedure PL1_MAXIINV_IMPORTWE()
// Déclaration des variables
bOk est un booléen = Faux
nIdFTPConnect est un entier
sauvDossier est une chaîne

nIdFTPConnect = FTP_CONNECT("xxx.yyyyy.fr", "nnnnnnnn", "*****") // en dur pour simplifier la démo
SI (nIdFTPConnect >= 0) ALORS
// vérifier la présence du dossier source en se plaçant dedans
SI PAS FTPRepEnCours(nIdFTPConnect,"/Developpeur/MaxiINV/IS-MS/Data") ALORS // en dur pour simplifier la démo
Erreur("Répertoire source introuvable.", ErreurInfo())
SINON
SI FTPFichierExiste(nIdFTPConnect, "stockproduit.fic") ALORS // on s'assure que le fichier source existe
sauvDossier = PL_STOCK_PRODUIT..Répertoire
HFerme (PL_STOCK_PRODUIT)
fSupprime (sauvDossier+[fSep()]+PL_STOCK_PRODUIT..NomPhysique+".*")

Info ("[DEBUG]Ancien fichier existe ?",HFichierExiste(PL_STOCK_PRODUIT)) // en théorie on doit avoir 0 : c'est le cas
HChangeRep(PL_STOCK_PRODUIT,"") // pour voir ce que ça fait : je "détache" le fichier de son répertoire de prod (on bascule donc au fin fond d'une arborescence obscure de l'Android)
Info ("[DEBUG]Répertoire",PL_STOCK_PRODUIT..Répertoire) // juste pour voir

SI PAS FTPRécupère (nIdFTPConnect, FTPRepEnCours(nIdFTPConnect)+["/"]+"stockproduit.fic", sauvDossier+[fSep()]+"stockproduit.fic") ALORS
Erreur ("Echec récup FTP", ErreurInfo())
SINON
Info ("[DEBUG]Nouveau fichier existe ?",HFichierExiste(PL_STOCK_PRODUIT)) // en théorie toujours 0 car on pointe toujours "dans le vide"
Info ("[DEBUG]Répertoire",PL_STOCK_PRODUIT..Répertoire) // pour contrôler avant / après

HChangeRep(PL_STOCK_PRODUIT,sauvDossier) // on se rebranche sur le bon dossier

Info ("[DEBUG]Répertoire",PL_STOCK_PRODUIT..Répertoire) // pour contrôler avant / après
Info ("[DEBUG]Nouveau fichier existe ?",HFichierExiste(PL_STOCK_PRODUIT)) // là on est bien à 1

SI PAS HRéindexe(PL_STOCK_PRODUIT) ALORS // allez on va le faire explicitement pour le principe même si ça se débrouille sans
Erreur ("Echec réindexation",HErreurInfo())
SINON
bOk = Vrai
SI HLitRecherchePremier(PL_STOCK_PRODUIT,Numero,"003375") ALORS
// là on devrait avoir 003375, 291 et "" (contenu du fichier récupéré depuis le serveur FTP)
// et à la place, j'ai 003375, 13 et "NDS" qui correspond au fichier que j'ai supprimé juste avant la récup FTP
Info("[DEBUG]", PL_STOCK_PRODUIT.Numero, PL_STOCK_PRODUIT.ID_EMPL, PL_STOCK_PRODUIT.Observation)
SINON
Info("[DEBUG]","pas trouvé l'enregistrement",HErreurInfo())
FIN
FIN
FIN
SINON
Erreur ("Fichier source non disponible", ErreurInfo())
FIN
FTPDéconnecte(nIdFTPConnect)
FIN
FIN

RENVOYER bOk
Membre enregistré
73 messages
Posté le 19 novembre 2021 - 09:18
Bon, ce n'est pas beau mais la fonction EDITER ne fonctionne pas pour enlever l'indentation.
Membre enregistré
24 messages
Posté le 19 novembre 2021 - 09:55
Bonjour

AMHA, tu oublies de supprimer le .ndx et de l'importer en même temps que le .fic
Schématiquement, je ferai comme ça :
si hferme(ton.fic) alors hraz(ton.fic)
si fSupprime(ton.fic) alors fSupprime(ton.ndx) ; vérifier si supprimés par fFichierExiste() pour ton.fic et ton.ndx
? à voir si besoin fsupprime() dans fRepCache() au cas où ?
récupérer sur ton FTP ton.fic ET ton.ndx
Réactualiser tes champs
... etc ...
Membre enregistré
1 825 messages
Posté le 19 novembre 2021 - 11:02
Il peut aussi y avoir un fichier .mmo
A supprimer et importer si il existe
Posté le 19 novembre 2021 - 12:35
en plus de ne pas supprimer le ndx et mmo, tu ne fais AUCUN controle sur les retour de fonction...
Tu n'as donc aucun moyen dans ton code de savoir si par exemple le hferme ou le fsupprime a effectivement fonctionné ou si un message d'erreur est disponible...

Donc, en premier, ajoute un test sur la valeur de retour de CHAQUE fonction, affiche les erreurs éventuelles, et bien sur supprime les ndx et mmo.
Membre enregistré
73 messages
Posté le 19 novembre 2021 - 12:36
Amateur23 a écrit :
Bonjour

AMHA, tu oublies de supprimer le .ndx et de l'importer en même temps que le .fic
Schématiquement, je ferai comme ça :
si hferme(ton.fic) alors hraz(ton.fic)
si fSupprime(ton.fic) alors fSupprime(ton.ndx) ; vérifier si supprimés par fFichierExiste() pour ton.fic et ton.ndx
? à voir si besoin fsupprime() dans fRepCache() au cas où ?
récupérer sur ton FTP ton.fic ET ton.ndx
Réactualiser tes champs
... etc ...

Merci de t'être penché sur mon problème. J'ai passé en revue et re-testé tous les points que tu abordes :
- Je supprime ".*", donc fic, ndx, mmo et tutti quanti (re-vérifié).
- le ndx est régénéré automatiquement, mais je le régénère explicitement avec le HRéindexe (en plus il est énorme ça prend trop de temps). Le problème est le même si je l'importe aussi (je viens de le re-tester).
- HRaz à moins que je me trompe de longue date initialise un enregistrement et non un fichier, mais je teste qd-mm ... ça ne change rien.
- je viens d'ajouter fFichierExiste qui renvoie bien faux mais j'avais déjà visualisé la suppression avec l'explorateur de fichiers de l'appareil ET avec HFichierExiste
- j'ai ajouté un test sur le HFerme : il renvoie Vrai
- j'ai aussi vidé le cache de l'appli (à la main, il faut encore que je teste avec le fRepCache et compagnie, mais notre appli ne met rien dans ce cache ou sinon pas explicitement)

A ce stade, toujours rien de concluant.
Membre enregistré
24 messages
Posté le 20 novembre 2021 - 03:25
J'ai testé en réel la persistance des FIC sur Android et j'ai remarqué que les gros fichiers ne semblent pas être effacés efficacement avec fSupprime() donc pour éviter les tests, il faut faire un HCréation(tonfichier) et l'aide conseille le HRaz() si besoin
Après ça, pourquoi tu fais des HChangeRep() ?
Pourquoi ne pas directement importer ton fichier dans fRepDonnées() ?
... FTPRécupère (nIdFTPConnect, FTPRepEnCours(nIdFTPConnect)+["/"]+"stockproduit.fic", fRepDonnées()+[fSep()]+"stockproduit.fic") ...

Pour mon test, j'ai généré l'APK en y joignant un gros FIC dans "Répertoire courant" qui est fRepEnCours() puis je le copie dans fRepDonnées() dans l'appli, je le supprime, copie, réindexe encore et encore et ça marche bien
... SI fCopieFichier(fRepEnCours() +fSep+ "tonfichier.fic", fRepDonnées() +fSep+ "tonfichier.fic", frConfirmer) ALORS ...





J'ai testé HRéindexe() sur le gros fichier lignecde.fic et c'est assez rapide même en ayant supprimer le NDX pour voir




Tu peux aussi ajouter une jauge pour le FTP, ça permet de voir où on en est du transfert
... FTPRécupère (nIdFTPConnect, FTPRepEnCours(nIdFTPConnect)+["/"]+"stockproduit.fic", fRepDonnées()+[fSep()]+"stockproduit.fic", "FTP_Jauge") ...
//////
PROCÉDURE FTP_Jauge(z est entier, az est entier)
//trace(az +" - "+ z)
Jauge1..BorneMax = z
Jauge1 = az
RENVOYER az
/////





Pucpood a écrit :
Amateur23 a écrit :
Bonjour

AMHA, tu oublies de supprimer le .ndx et de l'importer en même temps que le .fic
Schématiquement, je ferai comme ça :
si hferme(ton.fic) alors hraz(ton.fic)
si fSupprime(ton.fic) alors fSupprime(ton.ndx) ; vérifier si supprimés par fFichierExiste() pour ton.fic et ton.ndx
? à voir si besoin fsupprime() dans fRepCache() au cas où ?
récupérer sur ton FTP ton.fic ET ton.ndx
Réactualiser tes champs
... etc ...

Merci de t'être penché sur mon problème. J'ai passé en revue et re-testé tous les points que tu abordes :
- Je supprime ".*", donc fic, ndx, mmo et tutti quanti (re-vérifié).
- le ndx est régénéré automatiquement, mais je le régénère explicitement avec le HRéindexe (en plus il est énorme ça prend trop de temps). Le problème est le même si je l'importe aussi (je viens de le re-tester).
- HRaz à moins que je me trompe de longue date initialise un enregistrement et non un fichier, mais je teste qd-mm ... ça ne change rien.
- je viens d'ajouter fFichierExiste qui renvoie bien faux mais j'avais déjà visualisé la suppression avec l'explorateur de fichiers de l'appareil ET avec HFichierExiste
- j'ai ajouté un test sur le HFerme : il renvoie Vrai
- j'ai aussi vidé le cache de l'appli (à la main, il faut encore que je teste avec le fRepCache et compagnie, mais notre appli ne met rien dans ce cache ou sinon pas explicitement)

A ce stade, toujours rien de concluant.
Membre enregistré
73 messages
Posté le 22 novembre 2021 - 15:43
Bonjour,

Pour commencer, je me rends compte que je dois préciser mon problème : dans les faits les fichiers sont effectivement bien rapatriés sur l'appareil, avec les bonnes données. Si je les ouvre avec WDMap, il y a bien ce qu'il faut à l'intérieur. Là où les problèmes commencent, c'est quand je veux visualiser les données tout de suite après l'import : c'est là que je vois ce qui est censé être écrasé.
Si je redémarre l'appli , là les données sont justes.

Reprenons point par point les remarques intéressantes de Amateur23 :

- Concernant le ndx, c'est le transfert ftp qui peut être long quand mes clients ont un réseau faiblard.

- Pour stocker mes données, j'utilise un dossier situé sur SysRepCarteStockage() qui est conservé en cas désinstallation de mon appli, ce qui n'est pas le cas de fRepDonnées. Mais c'est un sujet à lui tout seul avec les changements sous Androïd 10/11.

- Dans le code que j'ai fourni, le HChangeRep est en effet inutile. C'est une tentative parmi d'autres pour arriver à mes fins.

- Bonne idée le HCréation : j'ai essayé. Malheureusement c'est pire : mon fichier est vide à la fin de l'opération et impossible de recréer les index.

Je commence à croire que mon appli est maraboutée. Mais allez quand-même jusqu'à la fin du post, j'ai peut-être le commencement d'un vague début de piste.

Ci-dessous ma dernière mouture qui n'est pas plus concluante que le reste :

SI HLitRecherchePremier(PL_STOCK_PRODUIT,Numero,"003375") ALORS
Info("[DEBUG]état initial", PL_STOCK_PRODUIT..Répertoire, PL_STOCK_PRODUIT..NomPhysique, PL_STOCK_PRODUIT.Numero,...
PL_STOCK_PRODUIT.ID_EMPL, PL_STOCK_PRODUIT.Observation)
// à ce niveau on a toujours les données correspondant à ce qu'il y a réellement dans le fichier
// on les change pour voir
PL_STOCK_PRODUIT.ID_EMPL = 13 // dans le fichier qu'on va importer c'est = 291
PL_STOCK_PRODUIT.Observation = "NDS" // dans le fichier qu'on va importer c'est = ""
HModifie(PL_STOCK_PRODUIT)
Info("[DEBUG]après forçage", PL_STOCK_PRODUIT..Répertoire, PL_STOCK_PRODUIT..NomPhysique, PL_STOCK_PRODUIT.Numero,...
PL_STOCK_PRODUIT.ID_EMPL, PL_STOCK_PRODUIT.Observation)
// ici on voit que le HModifie est bien pris en compte
SINON
Info("[DEBUG]pas trouvé l'enregistrement de test inital",HErreurInfo())
// mais on continue qd-mm
FIN
// ce qui suit permet de RAZ l'enregistrement en mémoire et après de supprimer tous les autres
// même si on change l'ordre ça ne change rien
HRAZ (PL_STOCK_PRODUIT)
SI PAS HCreation(PL_STOCK_PRODUIT) ALORS
Erreur ("Echec de création", HErreurInfo())
SINON
SI HFichierExiste(PL_STOCK_PRODUIT) ALORS
// avec le HCréation, on est dans ce cas. Le ndx est déjà créé aussi.
Info ("[DEBUG]stockproduit existe", PL_STOCK_PRODUIT..Répertoire, PL_STOCK_PRODUIT..NomPhysique)
SINON
Info ("[DEBUG]stockproduit n'existe pas", PL_STOCK_PRODUIT..Répertoire, PL_STOCK_PRODUIT..NomPhysique)
FIN
FIN
SI HFerme (PL_STOCK_PRODUIT) ALORS
// ça ferme à tous les coups sans problème
SI PAS fSupprime (PL_STOCK_PRODUIT..Répertoire+[fSep()]+PL_STOCK_PRODUIT..NomPhysique+".*") ALORS
// en réalité ça n'arrive jamais sur mon Zebra TC25
Erreur ("Echec de suppression", ErreurInfo())
// mais on continue qd-mm
FIN
// on pousse les tests à fond :
SI fFichierExiste(PL_STOCK_PRODUIT..Répertoire+[fSep()]+PL_STOCK_PRODUIT..NomPhysique+".fic") ALORS
// ça n'arrive jamais
Info ("Tiens, le fichier fic existe encore ...")
// mais on continue qd-mm
SINON
Info ("stockproduit.fic est bien supprimé") // vrai : vérifié avec le gestionnaire de fichier (plus de ndx non plus)
FIN

SI PAS FTPRécupère (nIdFTPConnect, FTPRepEnCours(nIdFTPConnect)+["/"]+PL_STOCK_PRODUIT..NomPhysique+".fic",...
PL_STOCK_PRODUIT..Répertoire+[fSep()]+PL_STOCK_PRODUIT..NomPhysique+".fic") ALORS
Erreur ("Echec récup FTP", ErreurInfo()) // ça n'arrive jamais
SINON
// HOuvre(PL_STOCK_PRODUIT) // n'a aucune influence
SI PAS HRéindexe(PL_STOCK_PRODUIT) ALORS
Erreur ("[DEBUG]Echec réindexe du fichier importé", HErreurInfo())
SINON
TANTQUE HRéindexationEnCours(PL_STOCK_PRODUIT) <> 0
FIN
Info("[DEBUG]NbEnr du fichier importé", HNbEnr(PL_STOCK_PRODUIT))
SI HLitRecherchePremier(PL_STOCK_PRODUIT,Numero,"003375") ALORS

// mon enregistrement est systématiquement introuvable depuis l'utilisation HCréation

// etc


Enfin, si on oublie HCréation, ça fonctionne si je viens de démarrer l'appli. Ça ne fonctionne plus à partir du moment où ce fichier est impliqué dans une requête exécutée avec HExécuteRequête. J'ai tenté un HAnnuleDéclaration lorsque celle-ci n'est plus utile, mais ça ne change rien.

Ça vous inspire ?
Membre enregistré
46 messages
Popularité : +1 (1 vote)
Posté le 22 novembre 2021 - 16:40
Bonjour, tes test sont fait en quel mode ? simulateur ou appareil mobile ? le comportement n'est pas le même. Cordialement.

--
JGV
Membre enregistré
73 messages
Posté le 22 novembre 2021 - 16:57
Pour m'affranchir de ces considérations, je fais mes tests sur un (même 2) appareil, en mode 'installé' et non en 'GO'.
Membre enregistré
1 825 messages
Posté le 22 novembre 2021 - 18:38
Au risque de me répéter
Le plus sur est de créer la connexion et d'utiliser HFermeConnexion
Avant la supression des fichiers
Puis de refaire la connexion ou de changer de répertoire
Mais bon, il faut peut être accepté de le faire
Membre enregistré
73 messages
Posté le 23 novembre 2021 - 09:30
Popoy a écrit :
Au risque de me répéter
Le plus sur est de créer la connexion et d'utiliser HFermeConnexion
Avant la supression des fichiers
Puis de refaire la connexion ou de changer de répertoire
Mais bon, il faut peut être accepté de le faire

Bonjour Popoy,
Je viens de tester ta piste qui est intéressante aussi il est vrai. J'ai créé une connexion à laquelle j'ai associé mes fichiers. J'ai fébrilement lancé mon test, plein d'espoir, malheureusement sans résultat.
J'ai fait un 'gros paquet' que j'ai envoyé au support, on verra si ça les inspire.
Membre enregistré
1 825 messages
Posté le 23 novembre 2021 - 13:25
Ok merci de ton retour
Membre enregistré
73 messages
Posté le 24 novembre 2021 - 10:09
Bonjour,

Ca y est j'ai trouvé !! C'était vicelard et je pense que ça peut vous être bien utile de savoir de quoi il retourne.

Dans une des fenêtres utilisées quand le problème se posait, une variable source de données accueille le résultat d'une requête SQL elle-même basée sur le fichier qui pose problème (PL1_STOCK_PRODUIT).
Ci-dessous le code dans 'Fin d'initialisation' de cette fenêtre
sdSrcRequete est une Source dede Données

SI Faux=HExécuteRequêteSQL(sdSrcRequete, hRequêteDéfaut, "SELECT COUNT(*) AS COUNT FROM PL_STOCK_PRODUIT WHERE Numero = '" + PL_STOCK_PRODUIT.Numero+"'") ALORS
Erreur(HErreurInfo(hErrComplet))
FIN

Puis quelques traitements basés sur le résultat de la requête et c'est tout.
Il a suffit qu'une fois la requête devenue inutile j'ajoute l'instruction
SI PAS HLibèreRequête(sdSrcRequete) ALORS Erreur ("Echec de libération de requête", HErreurInfo())

pour que tout rentre dans l'ordre.

Donc, contrairement à ce que m'a affirmé le support gratuit, il y a bien des choses stockées dans des caches ou des piles et de manière pas si temporaire que ça puisqu'en l'occurrence, il s'agissait d'une source de donnée déclarée localement dans une fenêtre qui était déjà fermée au moment du problème !

Comme quoi il ne faut jamais partir en laissant la porte ouverte, même pas celle du cagibi !

Merci à tous de votre implication.
Membre enregistré
1 825 messages
Posté le 24 novembre 2021 - 23:01
En effet, cela doit être systématique la libération de requête
(Personnellement des que j'exécute une requête je rajoute sa libération dans la fermeture de fenêtre)
Mais franchement au vu du début de la question je ne m'en serais pas douté
Posté le 25 novembre 2021 - 13:30
> Donc, contrairement à ce que m'a affirmé le support gratuit, il y a bien des choses stockées dans des caches ou des piles et de manière pas si temporaire que ça puisqu'en l'occurrence, il s'agissait d'une source de donnée déclarée localement dans une fenêtre qui était déjà fermée au moment du problème !

En l'occurrence, c'est clairement indiqué dans l'aide des sources de données :

A la fermeture de l'application (ou du traitement où la source de données a été déclarée), la source de données sera automatiquement détruite.
Une source de données globale est toujours globale au contexte HFSQL dans lequel elle a été déclarée.


Donc, sauf si tu as un contexte HF uniquement pour ta fenêtre, fermer la fenêtre ne détruit pas la source de données...

Mais bon, c'est clair que vu les symptômes, j'aurais pas cherché par la non plus.
Membre enregistré
73 messages
Posté le 02 décembre 2021 - 08:59
Bonjour Argus,
PC Soft me donne le même argument mais je ne trouve pas que ce soit si clair que ça :
"Une source de données 'globale' est toujours ....." : en quoi la mienne est-elle globale étant déclarée dans une fenêtre (fermée) ? Ou alors, ce premier 'globale' est de trop dans la phrase... Oui, en fait ça doit être ça, la bonne phrase doit sans doute être :
"Une source de données est toujours globale ......."
L'important en dehors du fait que je sois débloqué, c'est que l'expérience puisse servir à d'autres : toujours bien HLibérer !
Et merci encore à tous.