[Résolu] Impossible d'afficher un rapport existant

[yves30]

Bonjour

Je rencontre des difficultés avec un fichier de BD, créé il y a environ huit ans, dans lequel j'effectue régulièrement diverses saisies, à savoir, des données généalogiques concernant des personnes décédées depuis plus de deux siècles (donc, rien de sensible, ni d'indiscret).

Or, après avoir tout récemment créé un rapport dans cette BD, je viens de découvrir qu'il m'était impossible d'afficher ce rapport.

Dans ce fichier, les tables, les requêtes, les formulaires,etc. : tout fonctionne de manière habituelle et satisfaisante... sauf les rapports.

Dans le mode édition, tout se déroule a priori normalement, puisque je peux créer ou modifier un rapport, mais il m'est totalement impossible d'ouvrir un rapport existant (impossible de l'afficher, pour en visualiser le contenu, pour contrôler le rendu des formats, etc.) : la simple activation de la commande /Outils/Exécuter le rapport (ou, dans la fenêtre principale, un simple double-clic sur le nom du rapport) entraîne systématiquement le plantage de LO, avec, à la réouverture de l'application, la classique procédure de récupération du fichier.

Voici le fichier en question : https://www.cjoint.com/c/JGwplTyEd6k

Précisions diverses :
1) Version de LibreOffice : 6.4
2) Version de Java : 11.0.7
3) Poids du fichier de base de données posant problème : environ 10 Mo
4) À plusieurs reprises, j'ai utilisé le code « SHUTDOWN COMPACT » ou « CHECKPOINT DEFRAG », dans /Outils/SQL/Instruction à exécuter. En vain.
5) J'ai lancé le Testeur de fichier corrompu (version 2) proposé sur le Forum par bm92 : à la fin du processus, l'utilitaire affiche toujours le message "Ce document est dézippable, il peut être récupérable".
6) L'anomalie décrite ci-dessus ne se produit pas avec mes autres fichiers de BD (d'un volume inférieur) pour lesquels je peux donc, sans difficulté, créer, modifier et afficher des rapports.
7) J'ai testé le fichier sur mon autre machine, avec Mint 19 et LO version 6.3, et le résultat est le même : il m'est impossible d'afficher le rapport récemment créé, et toute tentative se solde par un plantage de LO.

Merci d'avance pour vos suggestions

[tintin]

Bonjour,

son poids m'empêche évidemment de le partager sur le Forum

Le fichier dépasse les 500 Ko acceptés et est inférieur à 15 Mo. Vous pouvez le joindre en passant uniquement par : http://www.cjoint.com/ Ceci pourra être un avantage dans la recherche d'une solution.

[yves30]

Merci pour cette précision, Tintin. J'ignorais cette possibilité.

Je m'excuse. Voici donc le fichier en question : https://www.cjoint.com/c/JGwplTyEd6k

[jeanmimi]

Bonjour,

impossible d'afficher le rapport récemment créé, et toute tentative se solde par un plantage de LO.

Je n'ai pas le plantage, mais le gel de LO, ce qui revient au même puisque je suis obligé de terminer le processus.

vos suggestions

Un exemple récent a montré un blocage des Rapports sans doute du à l'utilisation d'un filtre paramétré dans la boite de dialogue de la source du Rapport.
Je suggère de plutôt construire le Rapport sur une Requête avec un critère posé sur le champ à extraire.

Ajout : En faisant ce cette manière, le Rapport se lance très rapidement Cet exemple est basé sur une Requête avec un Type de BMS '11 Naiss' Rapport_sur_Requête_TypeBMS_11Naiss.odt

Je constate aussi que les Tables ne sont pas optimisées et consomment beaucoup plus d'octets qu'elles ne devraient.

[yves30]

Bonjour, Jeanmimi, et merci pour ton message que j'ai lu avec beaucoup d'attention.

I) J'ai tenté de suivre tes suggestions :

1) J'ai créé une requête (en mode ébauche) avec tri et filtre appropriés.
2) Dans les Propriétés du rapport, j'ai modifié le rapport que tu as ouvert, en réglant les champs de l'onglet Données comme suit :
- Type de contenu : Requête
- Contenu : la requête récemment créée
- Analyser l'instruction SQL : Oui
- Filtrer : pas de filtre
- Format de sortie du rapport : Texte ODF
(ces différents réglages sont-ils corrects ?)

Or, malheureusement, le rapport refuse d'afficher les champs de la requête que je viens de créer. J'ai alors voulu vérifier le contenu de la requête en question, mais il m'est impossible de l'ouvrir, ni en lecture, ni en modification. Toute tentative génère le message suivant :

Impossible de charger le contenu des données

Puis :

La requête va être ouverte en mode SQL

... ce qui ne m'éclaire pas davantage...

Par ailleurs, je me rends compte que toutes mes requêtes existantes présentent la même anomalie et sont actuellement impossibles à ouvrir !

II) Tu me dis également :

Je constate aussi que les Tables ne sont pas optimisées et consomment beaucoup plus d'octets qu'elles ne devraient.

J'ignore ce que signifie optimisation des tables, et si cela a un rapport avec la difficulté que je rencontre avec les rapports, mais, je suis prêt à prendre en compte tout conseil visant à améliorer mon fichier de BD. Par conséquent, pourrais-tu m'en dire un peu plus à ce sujet STP ?
Merci d'avance pour ton aide.

[jeanmimi]

J'ai alors voulu vérifier le contenu de la requête en question, mais il m'est impossible de l'ouvrir, ni en lecture, ni en modification.

Si c'est en rapport avec Java, la mise à jour se fait ici :
https://forum.openoffice.org/fr/forum/v ... =2&t=62683

J'ai créé une requête (en mode ébauche) avec tri et filtre appropriés.

Ce n'est pas tout à fait ce que j'avais écrit :

Requête avec un critère posé sur le champ à extraire

En pratique, dans la Requête que j'ai créée, j'avais entré le critère 11 Naiss dans la colonne du champ Type de BMS.
Un critère n'est pas un filtre, et semble bien mieux fonctionner (je ne sais pas pourquoi).

J'ignore ce que signifie optimisation des tables

Un exemple : dans ta Base, la Table affiche des dizaines de vois le même texte pour les lieux de naissance, de mariage, etc A chaque fois, le champs consomme de la mémoire pour stocker cette information et augmente ainsi le poids de la Base. Une Table optimisée ne stockerait que le l'ID du lieu (soit seulement 3 ou 4 digits au maximum); une Table supplémentaire contiendrait les quelques lieux répertoriés et un ID_lieu pour servir de source de données. Idem pour les autres informations redondantes.

[yves30]

Bonjour, Jeanmimi, et merci pour ton aide

Je dois t'avertir en préambule que, bien que j'utilise Base depuis de plusieurs années, mes connaissances concernant le fonctionnement interne de l'application sont extrêmement limitées.

1) Test sur l'autre machine

Entre-temps, j'ai pensé à une chose : j'ai deux machines avec Linux Mint, l'une avec la version 19, l'autre avec la version 20. J'ai donc testé la BD problématique sur la seconde machine (Mint 20, avec LO 6.4, et Java Ubuntu11.0.7). Et j'ai constaté que sur cette machine, je pouvais ouvrir les requêtes (en affichage et en modification), mais pour ce qui est des rapports, le problème est le même : je peux ouvrir le rapport en édition, mais dès que je l'exécute, dès que je cherche à l'afficher, LO se fige...

2) Filtre ou critère

jeanmimi a écrit: Requête avec un critère posé sur le champ à extraire

J'ai écrit filtre, mais ce n'était peut-être pas le terme approprié. En fait, après avoir ouvert la requête en mode édition, j'ai simplement ajouté un critère alphanumérique (du type LIKE 'xyz') dans la colonne du champ approprié.

3) Concernant Java

Si c'est en rapport avec Java, la mise à jour se fait ici

J'ignore si c'est en rapport avec Java (mais c'est pas impossible) : ma version de LO, installée il y a quelques semaines, m'indique (dans /Options/Libreoffice/Avancé) : Ubuntu 11.0.7, mais je n'en sais pas plus à propos de Java...

Toutefois, j'ai suivi le lien que tu m'as indiqué et j'ai installé la dernière version (1.8.0_261) en respectant les instructions. Ensuite, dans /Outils/LibreOffice/Avancé, j'ai constaté que LO avait bien pris en compte la nouvelle installation de Java (1.8.0_261) : je l'ai donc activée, puis j'ai relancé l'application.

Malheureusement, le comportement de la BD est le même, même avec Java 1.8.0_261 :
- Je peux créer, afficher ou modifier une requête ;
- Je peux créer ou modifier un rapport ;
- Mais si j'essaie d'afficher celui-ci, LO se fige...

Cependant, sur la première machine, il me faudra sans doute mettre à jour Java et tester à nouveau mon fichier de BD.
Après vérification dans mes autres bases de données, je confirme que cette anomalie (impossibilité d'afficher un rapport) ne se produit que sur ce fichier.

4) Optimisation des tables

Concernant les informations redondantes, je préfère ouvrir ultérieurement un nouveau fil sur ce sujet, pour ne pas tout mélanger et éviter d'accumuler plusieurs thèmes dans le même fil de discussion (à moins que ce soit en relation avec mon questionnement sur les rapports ?)

[jeanmimi]

mais pour ce qui est des rapports, le problème est le même : je peux ouvrir le rapport en édition, mais dès que je l'exécute, dès que je cherche à l'afficher, LO se fige..

Si c'est le Rapport avec un filtre dans la Table, ce serait assez logique.
Que se passe-t-il si le Rapport à comme source de donénes, une Requête avec un critère sur un des champs ?

[yves30]

Merci pour ton aide, Jeanmimi,

Si c'est le Rapport avec un filtre dans la Table, ce serait assez logique.

Pas du tout : j'ai effectué les modifs que tu m'as suggérées : j'ai bien supprimé le filtre dans le rapport et j'ai pris comme source de rapport une requête avec un critère produisant le même effet que le filtre supprimé.

Que se passe-t-il si le Rapport a comme source de données, une requête avec un critère sur un des champs ?

il se passe ce que j'ai dit plus haut : je peux créer ou modifier le rapport en question, mais si j'essaie d'afficher celui-ci, LO se fige...

[jeanmimi]

j'ai pris comme source de rapport une requête avec un critère produisant le même effet que le filtre supprimé.

Pour tester, quel critère as-tu choisi, et sur quel champ de la Requête ?

[yves30]

Pour tester, quel critère as-tu choisi, et sur quel champ de la Requête ?

Le filtre supprimé dans l'ancien rapport portait sur le champ alphanumérique TypeBMS, comme '1*'

Dans la nouvelle requête, colonne TypeBMS, j'ai ajouté le critère LIKE '1*'

[HRk2o]

Bonjour,

j'ai effectué qqs tests du rapport dont voici les résultats:

- sur AOo, ça plante!
- sur LO 6.4.5,ça plante avec le rapport d'origine; pizza colorée sans fin!

J'ai créé une nouvelle requête de la table fondée sur un dialogue basé sur TYPEBMS;
une copie du rapport basé sur cette requête donne les résultats suivants:
- 1) TYPEBMS = 1% => affichage de 5123 pages après pizza colorée et pages rapport tremblant; ça doit bien prendre ds les 10mn; ça représente + de 22000 lignes
- 2) TYPEBMS = 10% => affichage de 5128 pages; durée itou;
- 3) TYPEBMS = 11% => affichage de 4 pages assez rapide.

voilà si ça peut vous aider!

suis d'accord avec jeanmimi pour l'optimisation = +1

@+

[yves30]

Merci HRk2o pour ta contribution

Malheureusement, ton message m'apporte plus de questions que de réponses :

Que signifie par exemple :

pizza colorée sans fin

... ou encore :

table fondée sur un dialogue basé sur TYPEBMS

Est-ce que cela désigne une table ne contenant que le champ TypeBMS ?
... également :

rapport tremblant

Qu'est-ce que c'est ?

Et que signifient les trois pourcentages TYPEBMS = 1%, etc.

Je devine que le fichier étant très lourd, le traitement peut prendre du temps ou peut finir par planter.
Selon vous, est-ce que je dois être plus patient, chaque fois que je demande l'affichage d'un rapport, et ne pas tout de suite relancer l'application ?
Où se situent mes erreurs ? Où ai-je failli ?...

Est-ce que vous pourriez, l'un ou l'autre, m'indiquer ce que, selon vous, je devrais faire pour corriger ma BD ?

suis d'accord avec jeanmimi pour l'optimisation = +1

Que signifie concrètement optimiser. Par exemple, pour reprendre l'exemple de Jeanmimi, les lieux sont contenus dans une table dédiée Lieu, qui ne contient qu'un champ Lieu. Est-ce que, pour cette table par exemple, j'aurais dû créer un second champ (un champ clé avec compteur automatique) ? Est-ce que ça aurait changé quelque chose dans le problème qui me préoccupe ?

Comme vos pouvez vous en rendre compte par toutes mes questions, je suis très ignorant d'un point de vue technique, mais, si on m'explique les choses, je suis peut-être capable de corriger mes maladresses : je crois que je ne manque pas de courage...

Merci d'avance pour votre aide et vos précisions.

[jeanmimi]

A tester, en entrant le critère comme décrit ici :
https://wiki.documentfoundation.org/Faq/Base/132/fr
Est-ce que le traitement est plus rapide et plus stable ?

[yves30]

Merci pour le lien, Jeanmimi, mais j'utilise déjà LIKE en mode ébauche (ou édition ou modification), ainsi que l'astérisque d'ailleurs.

J'utilise LIKE, notamment dans les critères d'une requête, comme dans celle que j'ai construite à la suite de ta suggestion.

Exemple : LIKE 'A*', pour ne retenir que les entrées commençant par A.

[HRk2o]

Rebonsoir,

avec qqs images, la compréhension peut être plus facile

Relations.png

tables.png

Requête.png

ps: j'opère sous OsX; qd l'application rame, apparait un disque animé multicolore !
@+

[jeanmimi]

Que signifie concrètement optimiser. Par exemple, pour reprendre l'exemple de Jeanmimi, les lieux sont contenus dans une table dédiée Lieu, qui ne contient qu'un champ Lieu. Est-ce que, pour cette table par exemple, j'aurais dû créer un second champ (un champ clé avec compteur automatique) ? Est-ce que ça aurait changé quelque chose dans le problème qui me préoccupe ?

Oui, c'est ça.
Les copies d'écran de HRk2o illustrent bien ta conclusion.
La conséquence : un lieu sera stocké dans la Table T_NomTitulaire seulement par son ID_LIEU soit 1, 2 ou 3 chiffres au lieu des dizaines de lettres actuellement. Sur 30 000 enregistrements ce sera une cure d'amaigrissement importante.

[yves30]

Bonjour, et HRk2o & Jeanmimi, et merci pour vos deux précieuses interventions.

Je comprends un peu mieux à présent ce que signifie optimiser, en ce qui concerne la table des lieux (ou d'autres tables, d'ailleurs). HRk2o, je conserve précieusement tes trois copies d'écran : il me faudra toutefois prendre le temps de les étudier un peu (comme vous avez pu le constater, je comprends vite, mais il faut m'expliquer longtemps !).

1) Expériences

Après avoir relu vos différents messages, j'ai tenté les deux expériences suivantes.

a) Première expérience
- Dans la requête, je n'ai conservé que les Vidal (il y en a peu dans mon arbre). Dans la colonne NomTitulaire, j'ai donc ajouté le critère LIKE 'Vidal,*' et j'ai enregistré la modification.
- Après avoir lancé la requête ainsi modifiée, j'ai constaté que LO n'avait retenu que 30 enregistrements (autrement dit, 30 Vidal).
- Enfin, j'ai exécuté le rapport correspondant (lequel repose désormais sur la requête que je viens de modifier) : et miracle ! Celui-ci a accepté de s'afficher ! Pour information, LO a mis 2 ou 3 secondes pour afficher le rapport avec les 30 Vidal.

b) Seconde expérience
Selon la même procédure, j'ai ensuite modifié le critère de la requête, ainsi : LIKE 'V*' (ce qui cette fois, représente 959 enregistrements), puis j'ai tenté d'exécuter le rapport correspondant, mais là, j'ai beaucoup attendu, sans rien voir venir... Au bout de 7 minutes, je me suis impatienté et j'ai relancé LO.

Je comprends à présent (ainsi que tu me l'as d'ailleurs précisé, Jeanmimi) que LO n'était probablement pas planté : il avait juste entamé un traitement de longue durée. Il s'agit donc d'un ralentissement dû au volume des données à traiter... D'où votre conseil d'optimiser mes tables.

2) Hypothèse de l'optimisation

Cette optimisation des tables implique un travail de correction lourd et délicat. Si c'est nécessaire, je l'accomplirai, mais je dois au préalable m'assurer de la procédure à suivre.

Je suppose que vous comprenez combien ce fichier de BD m'est précieux : il représente en effet huit ans de saisie, et je ne voudrais pas perdre mon travail, ni devoir saisir à nouveau des montagnes de données... C'est pourquoi, avant de me lancer, je souhaite, par précaution, mesurer les risques et, si possible, obtenir quelques précisions (sinon quelques certitudes) quant au résultat attendu.

Une fois optimisé, le fichier sera allégé, ce qui sans doute raccourcira les temps de traitement : c'est entendu. Toutefois, vu que mon fichier contient à ce jour 35 845 enregistrements, est-ce que, selon vous, cette optimisation (table Lieu, et autres...) permettra enfin d'obtenir l'affichage normal des rapports, et ce, dans un délai acceptable ?

3) Procédure envisagée

a) Suspendre toute nouvelle saisie jusqu'à nouvel ordre (de toutes façons, ce travail de saisie est à présent pratiquement achevé...)
b) Utiliser une copie du dernier état de mon fichier, et tenter l'aventure de l'optimisation
c) Créer une table jumelle de l'actuelle table T_Lieu (disons T_Lieu2), avec un champ compteur ID_Lieu2 et un champ Lieu2 (avec le même contenu que l'ancien champ Lieu).
d) Dans /Outils/Relations..., établir les mêmes relations qu'avec l'actuelle table T_Lieu

* Comment saisir de manière automatique les données de la table nouvellement créée, à partir des données existantes de la table T_Lieu ? Je crois avoir lu quelque part qu'il faut passer par un fichier tableur (copier la source dans Calc, puis, à partir de là, création de la table cible, etc.) ?...

* La dernière étape sera la suivante : effectuer les corrections dans les requêtes, puis dans les formulaires ?... avant de supprimer l'ancienne table devenue désormais inutile.

- Pouvez-vous apporter quelques réponses à mes divers questionnements ?
- Pouvez-vous me dire si cette procédure vous paraît convenir, les diverses étapes, ainsi que leur chronologie ?
- Pouvez-vous y ajouter vos propres précisions, mises en garde, conseils, etc. ?
- Connaissez-vous des pages (en français, si possible) décrivant l'une ou l'autre de ces routines (copie de champ, d'une table vers une autre, etc.), qui pourraient m'être utile ?...

Merci d'avance pour votre patience et votre aide.

[HRk2o]

Bonjour,

j'ai préparé une nouvelle base avec les tables nouvelles.
Il convient de renommer correctement les tables au final avant de modifier les requêtes et formulaires et rapports.
Il ne reste que la table "NomTitulaire" vers laquelle il faut importer les données modifiées/converties issues du tableau-onglet idoine- .

Par une Recherche et Remplacer, la chose est rapide à réaliser; puis un Copier et Coller le tableau vers la table et faire l'appariement .

Le plus ardu, je pense, sera de refaire les formulaires et requêtes, rapports.

Bon courage!

fichiers à récupérer :https://www.cjoint.com/c/JGysYrsdiCW

@+

[yves30]

Bonsoir, HRk2o, et merci pour tout le mal que tu te donnes

J'ai bien récupéré tes deux fichiers (le fichier Base et le fichier Calc).
J'étudie tout ça demain matin... et je te tiens au courant.

Le plus ardu, je pense, sera de refaire les formulaires et requêtes, rapports.

Ce n'est pas un problème pour moi : je saurai reconstruire les formulaires, les requêtes et le rapports dont j'aurai besoin (et supprimer ceux que je n'utilise plus).
La seule chose qui m'inquiète, c'est de ne pas perdre mes données suite aux modifications effectuées dans les tables.

************************************************************************

Bonjour, HRk2o,

Ce matin, j'ai ouvert tes deux fichiers (le tableau et la base) que j'ai examinés avec attention : encore une fois, je te félicite pour le travail accompli.

Concernant la base, tu as pris des initiatives qui faciliteront la transition :
- Tu as bien récupéré les tables en ajoutant un 2 à leur nom originel (T_Lieu = T_Lieu2).
- Tu as également conservé le nom des champs d'origine (Lieu = Lieu).
- Pour chaque table, tu as ajouté un champ compteur (ID), dont le nom commence par ID_ (par exemple, ID_Lieu, pour la table T_Lieu2). J'ai bien compris que c'est ce champ compteur qui servira à relier les tables entre elles (du côté du "1" de la relation).
- Tu as déjà importé les données de cinq tables : T_CoteRegistre2, T_Lieu2, T_Profession2, T_Religion2 et T_Type BMS2.
- Il reste donc à importer les données des deux dernières tables : T_NomTitulaire2 et T_Filiation2.

Cependant, avant de pouvoir me mettre au travail, j'ai besoin de connaître les réponses aux questions suivantes.

À ce propos, je souhaiterais m'excuser par avance de t'imposer la lecture de l'énorme pavé qui suit, rempli de remarques ou d'interrogations, dont certaines doivent te paraître bien inutiles, ou même, infantiles. J'apprécie tous les efforts que tu fais pour me rendre service, mais, comme tu peux le constater, je suis très lent à comprendre, et n'ai jamais été un initié. En effet, ce qui te paraît probablement aller de soi, n'est pas nécessairement évident pour moi. Je te demande donc de bien vouloir considérer les questions suivantes, avec patience et bienveillance.

Question 1
Procédure générale : par quoi dois-je commencer ?
- Par l'importation des données (actuellement contenues dans le tableau Calc) vers la table T_NomTitulaire2 (puis, dans un deuxième temps, vers la table T_Filiation2) ?
- Ou bien par la recréation des relations entre les tables (/Outils/Relations...) ?

Question 2
Concernant les relations entre les tables, voici les options que je retiens habituellement dans le panneau Relations de mes fichiers de BD :
- Options actualisation : Mise à jour en cascade (je souhaite que toute modification du contenu d'un champ soit répercutée dans le champ correspondant de la table fille).
- Options suppression : Aucune action (j'ignore si ce choix est pertinent).
Par conséquent, peux-tu me dire si, selon toi, ces choix sont valables ?... Ou déconseillés ?

Question 3
Concernant les images Relations et Table que tu as postées récemment.
Au moment d'établir une relation, par exemple, entre les tables T_Lieu2 et T_NomTitulaire2 :
- Du côté de T_Lieu2, je sélectionne le champ compteur (ID_Lieu).
- Mais du côté de T_NomTitulaire2, est-ce que je sélectionne les champs actuels (LieuNaissanceTitulaire, etc.) ou bien est-ce que je dois, au préalable, créer quatre champs spéciaux, tels que ceux figurant dans les images que tu as postées (RefLieuNaissanceTitulaire, etc.), et avec les réglages que tu as indiqués ?

Question 4

Il convient de renommer correctement les tables au final avant de modifier les requêtes et formulaires et rapports.

Est-ce que tu fais allusion au travail que tu as déjà accompli, ou bien est-ce qu'il s'agit d'un travail qu'il me reste à faire ? Car, si je dois renommer les tables, je ne sais même pas comment on fait...

Question 5

Il ne reste que la table "NomTitulaire" vers laquelle il faut importer les données modifiées/converties issues du tableau-onglet idoine. Par une Recherche et Remplacer, la chose est rapide à réaliser; puis un Copier et Coller le tableau vers la table et faire l'appariement.

Je devine qu'il s'agit là du travail délicat et risqué qu'il me reste à faire, de mon côté. Mais ces deux phrases sont pour moi très vagues et un peu énigmatiques. J'aurais vraiment besoin que tu m'expliques la procédure plus en détail, pas à pas, comme si tu t'adressais à un enfant, à un novice... Ouvre tel fichier, tel onglet, tel menu, choisis telle commande, sélectionne telle valeur, etc.

À te lire.

[tintin]

Bonjour,

D'où l'importance de travailler sur des copies et d'utiliser l'extension de Sauvegarde incrémentale d'Alain de La Chaume.

Ajout : Vu le message ci-dessous et trouvé ce sujet : https://forum.openoffice.org/fr/forum/v ... 81#p316881

[yves30]

Merci pour ta remarque, Tintin.
En matière de sauvegarde incrémentale, j'ai déjà installé l'extension timeStampBackup.

[HRk2o]

Bonsoir Yves30,

je vais essayer de te faire un pas à pas pour arriver à tes fins.
Je dois dire que ton problème est intéressant car je n'ai pas encore atteint ce volume de données dans les applications de service que j'ai développées. Le plantage et le ralentissement lors du rapport m'interpellent pour en rechercher les possibles causes.

Donc, je passe sur le côté prudence qd on effectue un travail de reconstruction, récupération etc... de fichier.
Les tables de la base sont reconstituées sauf 2, la « Filiation » et la «  NomTitulaire ».
Le tableau sert à finir la conversion des données des tables avant Importation vers les tables idoines de la base :

R1Q1 :
Finir la conversion des données concernées, la Filiation Avant la NomTitulaire en raison de l'ID Unique à obtenir pour avancer à l'étape suivante :
pour la « filiation », une ligne pose ? (en rouge) ; j'ai laissé telle quelle pour te permettre de saisir le bon ID_religion dans « Religionfamille »;

Code ID_refreligion.png

une fois fait => Trier suivant la priorité voulue => Copier toutes les données , puis :
=> Coller dans la table « T_Filiation » ;

Importvers table.png

une fenêtre s'ouvre ;
=> Ajouter données , suivant → appariement, sauf ID_Filiation qui sera créé automatiquement → Créer;

appariement.png

L'absence de message d'erreurs = données bien importées ; A Vérifier le contenu de la table.
Si Msg erreur => Mauvaise importation ou données mauvaises => Tout Supprimer ce qui a été importé partiellement, et Nettoyer la base de toute trace résiduelle de ces données par
→ Outil SQL : Checkpoint defrag et Shutdown compact
Il ne te reste plus qu'à recommencer l'opération après correction des erreurs de données.

Répéter les mms opérations pour la table NomTitulaire.
Une fois cette dernière table réalisée, tu peux récréer les relations telles qu'elles étaient à l'origine. En principe aucun msg d'erreur ne devrait s'afficher !

R2Q2 :
Ces paramêtres sont ceux que j'utilise habituellement ; et cela évite d'avoir des fiches 'fantômes'.

R3Q3 :
Ts les champs de la « NomTitulaire » en relation sont identifiés par REF_ xxx . Ils sont de format type 'Integer' que tu auras toutes recodés correctement selon chaque table relationnelle ; autrement, il y aura des surprises !!!

R4Q4 :
Pour Renommer table, requête, Formulaire et Rapport = Clic Droit + c ds la liste qui s'affiche !

Voilà! si tout s'est bien passé après cette reconstruction des tables, tu peux vérifier si la taille du fichier a évolué.

@+

[yves30]

HRk2o,

Merci, encore une fois, pour l'énorme travail que tu as accompli.
Je vais prendre le temps d'étudier tout ça et je te répondrai demain.

********************************************

Ce matin, j'ai commencé à lire ton message d'hier soir, en m'appuyant sur tes photos...

Je crois que j'ai compris les points suivants (R1Q1). Je dois m'occuper :
- D'abord, de la conversion des données de la table T_Religion2 vers T_Filiation2 ;
- Puis, de la conversion des données de la table T_Filiation2 vers T_NomTitulaire2 ;
- La mise en place des relations viendra après.

En suivant l'exemple de la photo "Table", j'ai ajouté le champ 'Ref_Religion' dans la table T_Filiation2 (Integer, Longueur : 10, Entrée auto : Non, Valeur auto : Non). C'est ce champ qui sera relié au champ 'ID_Religion' de la table T_Religion2.

Malheureusement, les choses se sont gâtées dès l'étape suivante :

pour la « filiation », une ligne pose ? (en rouge) ; j'ai laissé telle quelle pour te permettre de saisir le bon ID_religion dans « Religionfamille »;

Là, je ne comprends plus... Que signifie une ligne pose ? Je consulte la photo Code_Id_Refreligion, mais je ne suis pas plus avancé. Je crois deviner qu'il s'agit du fichier TABLEAUCONVERSION.ods ? Mais de quel onglet ? Mais surtout, que dois-je faire ?

une fois fait => Trier suivant la priorité voulue => Copier toutes les données , puis : => Coller dans la table « T_Filiation » ;

- Une fois fait : hélas, rien n'est fait pour l'instant...
- Trier suivant la priorité voulue : trier quoi ? Quel champ ? Quel onglet ? Quelle table ? Quelle sélection ? Et que signifie priorité ?
- Copier toutes les données : lesquelles ? Quelles colonnes ? Quelles lignes ?...

Bref, à ma grande honte, je n'ai pas été capable de franchir cette première étape de la procédure.

Je t'avoue que suis un peu découragé, et je commence à me demander si je n'ai pas trop présumé de mes forces... Je crains d'être incapable d'accomplir cette conversion. Je me demande s'il ne serait pas plus sage d'accepter mes limites et de renoncer à cette délicate manipulation.

Tu vois, quand je te disais que j'avais énormément de difficultés à comprendre les choses, il ne s'agissait pas de fausse modestie : je n'exagérais pas. De ton côté, tu as fait l'effort de me transmettre un pas-à-pas que n'importe quel utilisateur lambda comprendrait instantanément, mais pas moi.

En dehors d'une utilisation basique de LibreOffice, je n'ai aucune expérience, aucune connaissance, aucune intuition. J'ai donc besoin d'identifier très précisément, non seulement l'action à accomplir (sélectionner, copier, trier, supprimer, etc.), mais également la source et la cible de cette action (quel fichier, quel onglet, quelle table, quel champ, quelles lignes, quelles colonnes, etc.), sinon, je patauge, je tourne en rond, je suis désorienté...

Je crains de t'avoir fait perdre ton temps...

********************************************
Lundi 3 août 2020


Grâce aux différentes interventions des participants du Forum (Tintin, Jeanmimi...), et notamment grâce à l'aide active de HRk2o qui a effectué un travail impressionnant (face à mon incapacité à suivre ses instructions, il s'est chargé d'optimiser mes tables et m'a soutenu au cours de mes moments de découragement), cette BD, que, dès le départ, j'avais mal construite, est à présent corrigée (transfert du contenu des tables, création de champs indexés, etc.)

1) Résultat :
- Tout d'abord, le fichier est désormais un peu moins volumineux : 8,4 Mo, au lieu de 9,8 Mo.
- Mais surtout, je suis désormais en mesure de lancer l'affichage d'un rapport. Certes, si je lui associe les 35 841 enregistrements, le traitement est plutôt lent (20 mn !), mais LibreOffice accomplit sa tâche et ne se bloque plus. Et de toutes façons, puisque les rapports que j'aurai à afficher seront affectés d'un critère, je n'aurai jamais à traiter la totalité des enregistrements.

2) Suite à ce désagrément, j'ai compris deux choses essentielles pour éviter d'alourdir les traitements (surtout en cas de BD volumineuse) :
- Concernant les tables. Outre le champ principal (alphanumérique le plus souvent), une table mère doit impérativement contenir un champ indexé (ID, integer), distinct du premier champ : ce champ indexé permettra de créer une ou plusieurs jointures vers une table fille (relation 1-n) ;
- Concernant les rapports. Plutôt que d'utiliser un filtre (propriétés du rapport, onglet Données, champ Filtrer) dans un rapport construit à partir d'une table, il est préférable de construire ce dernier à partir d'une requête dédiée, puis d'ajouter à celle-ci un ou plusieurs critères dans la colonne du ou des champs appropriés (suggestion de Jeanmimi).

Je m'apprête donc à fermer de fil de discussion.

Encore une fois, merci à tous pour cette expérience qui m'a permis d'identifier mon problème et d'y trouver un remède, tout en préservant mes nombreuses années de travail.