|
| Started by Pascal BOULESTEIX, Feb., 23 2024 1:24 PM - 6 replies |
| |
| | | |
|
| |
Registered member
965 messages
Popularité : +16 (20 votes) |
|
Posted on February, 23 2024 - 1:24 PM |
Bonjour à tous
Je me bas contre un plantage aléatoire lors de la phase d'initialisation de mon application.
Il arrive peu souvent, mais bien assez, une erreur faisant état de checkForComodification.
Dans le processus d'init du projet, j'utilise des procédures globales dédiées à des fonctions de mise à jour de la base HFSQL.
Typiquement (et fortement résumé),
FUN_MAJ_START()
~~~~~~~
Procedure FUN_MAJ_START()
HLitPremier(SESSION_PARAM)
SI HTrouve(SESSION_PARAM) = Vrai ALORS
SESSION_PARAM.START=1
FIN
HFerme(SESSION_PARAM)
Est-il nécessaire d'utiliser HFerme ? Quelles sont les conséquences dans le flux de l'init ?
Pour les threads, on peut choisir le contexte HFSQL mais quid des simples procédures ?
--
Pascal Boulesteix
Applications Visiolittoral et WNat |
| |
| |
| | | |
|
| | |
| |
Registered member
328 messages |
|
Posted on February, 26 2024 - 8:19 AM |
Bonjour,
Je ne sais pas répondre précisément à ta question, toutefois je réagis à "Dans le processus d'init du projet, j'utilise des procédures globales dédiées à des fonctions de mise à jour de la base HFSQL.".
Pour ma part, je n'ai aucun traitement effectué à ce niveau, je n'y mets que des déclarations.
Pour ce qui est du contexte HFSQL, pour moi il n'y en a qu'un seul tant que tu restes dans le thread principal, ce qui est la situation par défaut. Il est "partagé" par tout ce qui gravite dans ce thread principal.
Quant à HFerme ... oui si SESSION_PARAM n'est plus utilisé, sinon ça ne sert à rien à mon avis puisque la prochaine sollicitation du fichier va l'ouvrir à nouveau automatiquement.
Bonne journée |
| |
| |
| | | |
|
| | |
| |
Registered member
3,355 messages
Popularité : +93 (137 votes) |
|
Posted on February, 26 2024 - 1:51 PM |
Salut
Dans le code que tu as mis le hferme ne sert à rien.
Après tu parles d'une mise à jour donc question
Quel type de mise à jour ? |
| |
| |
| | | |
|
| | |
| |
Registered member
965 messages
Popularité : +16 (20 votes) |
|
Posted on February, 26 2024 - 3:21 PM |
1 - Désolé, voulant faire simple, j'ai trop nettoyé le code exemple ; dans le vrai code, il y a u bien un hmodifie(SESSION_PARAM) avant le hferme.
2 - concernant la fin de la réponse de Pucpood, bien sur que le fichier sera ouvert automatiquement mais comme j'ai cettte #### erreur de comodification qui m'agace, je me suis dit que peut-être le contexte HFSQL avait du mal avec les hModifie émis dans plusieurs procédures différentes d'où l'idée de fermer les fichiers dans chacune des procédures.
--
Pascal Boulesteix
Applications Visiolittoral et WNat |
| |
| |
| | | |
|
| | |
| |
Registered member
477 messages
Popularité : +20 (20 votes) |
|
Posted on February, 26 2024 - 5:34 PM |
A supposer que le checkForComodification ait pour origine un accès concurrent à la base de données je verrouillerai plutot l'enregistrement en cours pour garantir un accès exclusif lors de sa modification. Le Hmodifie sans option debloquera l'enregistrement
SI HLitPremier(SESSION_PARAM,hBlocageEcriture) ALORS
SESSION_PARAM.START=1
HModifie(SESSION_PARAM)
FIN |
| |
| |
| | | |
|
| | |
| |
Registered member
328 messages |
|
Posted on February, 27 2024 - 8:30 AM |
Salut,
Après quelques recherches, je vois que dans le monde de Java, ça fait partie des erreurs connues un peu casse pied. Mais il y a des pistes.
Dans les traitements que tu penses impliqués dans l'erreur, y a-t-il une ou plusieurs boucle ? J'ai vu que ce genre d'erreur pouvait arriver lorsqu'un parcours de boucle était "cassé", "perturbé".
J'imagine par exemple un "POUR TOUT" sur un fichier pas tout à fait prêt.
Ou encore un boucle "POUR 1 A toto" où toto serait modifié en cours de route. |
| |
| |
| | | |
|
| | |
| |
Registered member
965 messages
Popularité : +16 (20 votes) |
|
Posted on February, 27 2024 - 4:17 PM |
Salut
J'ai déjà fait des recherches dans ce sens et il n'y a pas de boucle telle que tu le décris.
Ce qui est pénible, en mode GO sur le téléphone, c'est que même en mode strict, au sens debug WM, en demandant l'arrêt sur toutes les erreurs non gérées, le mode GO sort en signalant l'erreur mais pas en s'arrêtant sur la ligne de code posant problème.
Je vais refaire une revue de code.
--
Pascal Boulesteix
Applications Visiolittoral et WNat |
| |
| |
| | | |
|
| | | | |
| | |
|