Discussion :

[Jlmat]

Bonjour, me revoilà...

Bon j'ai identifié mon erreur presque par hasard bien que j'y ai passé des heures...

L'erreur comme certains d'entre vous l'avez supposé est en fait Basique et je dirais logique. Mais quand même! L'erreur était noyée dans un empilement de procédures et fonctions spécifiques imbriquées les unes dans les autres ce qui ne la rendais pas facilement détectable car les procédures et fonctions appartiennent à des unités différentes. Mon programme pèse près de 30000 lignes maintenant. Depuis quelques temps, je ressentais le besoin de faire un audit de mon code afin de voir la portée de mes variables, mais bon...

La vieille méthode du assigneFile, read, write et closefile fonctionne donc normalement. Habituellement lorsque j'utilise cette méthode ou un stringlist, je procède à l'ouverture et à la fermeture dans la même méthode. Cependant dans ce cas afin de ne pas générer trop d'accès disques avec les ouvertures et les fermetures, j'avais écrit certaines petites fonctions qui ne géraient pas les fermetures de fichiers. Si bien que dans l'enchevêtrement des chemins utilisant ces fonctions, certaines ne géraient pas les fermetures de fichiers. j'ai schématisé le processus très simplifié sur le schéma ci-dessous:



Dans la procedure globale de 1er niveau, l'ouverture et fermeture du fichier en question est bien géré. Mais dans certains cas, il y a appel à une autre fonction de contrôle (procédure x) où je n'avais pas mis la fermeture car pour économiser une relecture du fichier. Une fermeture étant géree plus loin. Malheureusement, entre temps, une procédure Y gére une réécriture du fichier par un fichier temporaire qui devrait être renommé. C'est là que ça plantait. Erreur 32 ou erreur 183 selon où l'on cherche l'erreur.

L'erreur remonte en réalité à la procédure X qui du fait que le fichier n'a pas été fermé interdit l'écriture ou le renommage du fichier en question dans la procédure y. Le Fichier temporaire est correct mais ne peut être renommé.
Ce qui m'a posé problème, c'est que je cherchais l'erreur dans la procédure y qui était correctement écrite. Puisque je je procédais à l'initialisation de l'index de lecture du fichier puis à la fermeture. Le fait que le fichier soit non renommable (en lecture seulement) n'interdisais pas ni l'utilisation du classique assignefile, ni le reset, ni le closeFile, c'est ce qui m'a perturbé.

Voilà, je suis donc obligé de restructurer la procédure x et Y en passant soit par un ObjetListe (je tente l'écriture d'un composant:) ou autre liste que je pourrais garder en mémoire ou sauvegarder et rappeler rapidement en cas de besoin (je cherche encore la solution idéale)...

Merci à tous de m'avoir aidé....

JJ

[popo]

Mais quand même! L'erreur était noyée dans un empilement de procédures et fonctions spécifiques imbriquées les unes dans les autres ce qui ne la rendais pas facilement détectable car les procédures et fonctions appartiennent à des unités différentes

Cependant dans ce cas afin de ne pas générer trop d'accès disques avec les ouvertures et les fermetures, j'avais écrit certaines petites fonctions qui ne géraient pas les fermetures de fichiers. Si bien que dans l'enchevêtrement des chemins utilisant ces fonctions, certaines ne géraient pas les fermetures de fichiers. j'ai schématisé le processus très simplifié sur le schéma ci-dessous

Voilà, je suis donc obligé de restructurer la procédure x et Y en passant soit par un ObjetListe

Fonctions spécifiques imbriquées les unes dans les autres :
Il n'est jamais bon d'avoir un code qui s'éparpille dans tous les sens.
Je te suggère de réaliser les E/S vers ce fichier au sein d'une unique classe et donc d'une unique unité.

Eviter trop d'accès disques :
Si tu passes ton temps à lire et écrire ce fichier, c'est qu'il y a un problème de conception quelque part.
Si les informations sur les personnes (rapport au nom "fPers") sont si volatile, je te suggère de les garder en mémoire ou d'utiliser un système prévu pour une lecture/écriture soutenue comme une base de données.
Pour les problèmes d'accès concurrent à un fichier, la règle d'or c'est que l'élément qui ouvre le fichier doit également être celui qui le ferme.
Cela rejoins l'idée précédente : une classe où l'ouverture du fichier serait faite au moment opportun (soit dans le constructeur, soit via une méthode qui vérifie si le fichier est ouvert et l'ouvre si besoin) et où sa fermeture serait réalisée dans le destructeur. Avec une base de donnée, l'ouverture du fichier serait simplement remplacée par l'ouverture d'une connexion SQL et sa fermeture (à noter, ça ne coûte pas grand chose de faire un open et un close)

Passer par un TObjectList :
Passer un paramètre supplémentaire à tes routines ne fera que rajouter de la complexité à ton code.
Encore une fois, si une classe gérait les E/S vers ton fichier, ça sera beaucoup plus simple mais surtout beaucoup plus maintenable.

[Jlmat]

Merci Popo pour tes remarques pertinentes!

Je suis d'accord que je dois revoir la répartition de mon code dans les différentes unités. De plus j'utilise des bibliothèques de fonctions utiles et générales ou spécialisés que j'ai développé durant de nombreuses années. J'ai donc commencé le programme par des fonctions simples auxquelles j'ai ajouté des subtilités (paramètres de recherches et d'optimisation des sorties de requêtes).

J'ai résolu le problème des accès disques par des tableaux dynamiques que je garde en mémoire ou dans des variables locales. Ces tableaux ne sont pas volumineux, alors ça ne freine pas les requêtes...
J'ai regroupé dans une même unité des fonctions sur les fichiers dont les formats sont différents. Je crois que je vais séparer ces traitements différents dans des unités différentes...

Concernant ta remarque sur le fichier personnes qui n'est qu'une partie, je garde en mémoire la personne courante sur laquelle il y a des opérations en cours. Mais pour certaines opérations de contrôle que je fais avant l'affichage de la liste des personnes accessibles selon le profil de l'utilisateur, j'ai une fonction d'analyse des données enregistrées afin de détecter certaines incohérences ou doublons d'informations par rapport à une autre base de données (mise à jour d'informations ou erreur de saisies...).
Bref, j'ai le défaut du débutant qui construit au fur et à mesure des besoins... Mais le projet sera fiable, il sera utilisé par des non-informaticiens alors, ça intérêt à ce que ce soit fiable et sécurisé, lol

J'arrive à un point de complexité où je dois réfléchir à une nouvelle organisation de les unités sources. Je suis en train du reste de rédiger un manuel de prise en main du logiciel ce qui m'aide à structurer et nommer correctement les différents modules du programme.

[SergioMaster]

Bonjour

Si tu passes ton temps à lire et écrire ce fichier, c'est qu'il y a un problème de conception quelque part.
Si les informations sur les personnes (rapport au nom "fPers") sont si volatile, je te suggère de les garder en mémoire

Je suis d'accord. Autant tout charger une fois et tout sauvegarder en fin de travail. Ce n'est pas comme s'il n'y avait pas les outils pour le faire !

- l'utilisation d'objets, comme j'ai pu le faire ici, voire pousser le bouchons et utiliser des voire de patterns (oui mes dernières lectures influent sur mes réponses ), une version optimisée des objets avec interface et tutti quanti (suggestion de lecture https://www.packtpub.com/application...mming-projects et pour approfondir https://www.packtpub.com/application...atterns-delphi)
- toujours en partant de fichier texte Firedac avec sa FDMemtable et FDReader/FDBatchMove/FDWriter qui permettrai, en sus, d'utiliser les données en cache

Bien sûr en partant du postulat qu'il s'agit d'une application monoposte quand je lis

Concernant ta remarque sur le fichier personnes qui n'est qu'une partie, je garde en mémoire la personne courante sur laquelle il y a des opérations en cours. Mais pour certaines opérations de contrôle que je fais avant l'affichage de la liste des personnes accessibles selon le profil de l'utilisateur, j'ai une fonction d'analyse des données enregistrées afin de détecter certaines incohérences ou doublons d'informations par rapport à une autre base de données (mise à jour d'informations ou erreur de saisies...).

alors qu'au début de la discussion on parlait de AssignFile / CloseFile je me dis qu'une petite base SQLite serait bienvenue ! Ou plus bien entendu Je suis presque certain qu'utiliser un SGBD simplifierait énormément le programme

[Jlmat]

Bonjour Sergio

alors qu'au début de la discussion on parlait de AssignFile / CloseFile je me dis qu'une petite base SQLite serait bienvenue ! Ou plus bien entendu Je suis presque certain qu'utiliser un SGBD simplifierait énormément le programme

C'est certain! Mais c'est la faute à popo qui prolonge la discussion, alors que le problème du AssigneFile et closefile est résolu.

Vous avez tous les deux raisons, mais la raison n'est pas toujours ce qui motive la passion des amateurs comme moi, mdr!

Bon, j'ai pris le chemin le plus court pour moi (je ne maitrise pas les bases de données en programmation, même si je les aies enseignées en théorie il y a longtemps et en travaux pratiques avec DBase III+). Mon projet pour l'instant m'apporte des solutions personnelles rapides ce dont j'avais besoin immédiatement en particulier pour l'impression des données sur des critères de recherche. Par ailleurs, je développe des outils qui sont indépendants des bases de données. Je garde sous le coude les réflexions qu'on a eu sur le sujet des bases de données car je dois me former...

Merci Sergio pour les liens fournis, je regarde toujours ce que l'on me donne... Et si j'ai l'air d'avoir laissé en suspend, des discussions précédentes, c'est parce que soit je cogite, soit parce que c'est trop tôt pour moi de conclure...