Base Cellules surnuméraires dans les rapports [RESOLU]

[mgl]

Bonjour,
J’ai créé un rapport qui comporte un en-tête de groupe et un détail :

• L’en-tête de groupe rapporte un ensemble d’infos uniques pour une structure : nom, prénom, adresse

• Le détail comporte tous les enregistrements d’un historique lié à la-dite structure.

Saut de page après le dernier élément d’historique de chaque structure.

Le détail comporte 5 champs de même hauteur, 1,25cm, collés les uns aux autres et alignés sur le haut du détail (coordonnée Y =0). La hauteur du détail est de 1,25cm.

Pas d’encadrement du détail ou des champs du détail.

Le rapport est au format odt (le format ods est illisible à cause du très grand nombre d’infos dans l’en-tête de groupe!)

Je m’attendrais à avoir un historique tabulaire avec un élément par ligne. Mais non !

1- Chaque élément est un tableau distinct des autres (mis en évidence par la création des bordures dans Writer : seule la ligne sélectionnée est encadrée de bordures).

2- Des cellules ,d’épaisseur apparemment nulle, se surajoutent sous certains champs du détail. (au format ods, cela est encore plus visible : le premier champ sera en A155, le 2e champ en E158, le 3e en L157, le 4e en P146 et le 5e en AA155)

Quand Writer récupère le rapport, il a du mal à gérer ce désordre. Si je dois modifier la hauteur de certaines lignes, l’affichage de la règle fonctionne pour quelques lignes puis n’est plus disponible. Je dois enregistrer le rapport puis l’ouvrir de nouveau pour récupérer la règle verticale.

Merci d’avance pour votre aide.

Ubuntu 18.04 LTS LO Version : 6.4.5.2 Build ID : 1:6.4.5-0ubuntu0.18.04.1
Threads CPU : 4; OS : Linux 5.4; UI Render : par défaut; VCL: gtk3;
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded

[PYS]

Bonjour @mgl

Pour aider les “aidants” à aider cela serait mieux de joindre une version minima de la base permettant de reproduire le problème. Je ne me vois pas tenter de créer ex nihilo une base et un rapport “au pif” avec le peu d’indications fournies pour tenter de reproduire le problème. Par ailleurs je ne comprends pas cette phrase :

Le rapport est au format odt (le format odf est illisible à cause du très grand nombre d’infos dans l’en-tête de groupe!)

odt est le format traitement de texte de l’odf…

Cordialement

[mgl]

Désolé : voici le lien vers la base de données Bidon : https://acloud2.zaclys.com/index.php/s/eoiWRtLj5p6LSq6
Plusieurs rapports présentent les même désordres. Celui explicités ci-dessus est Rp_Exemple_1_avec_historique

Merci encore

[mgl]

Coquille odf au lieu de ods corrigée dans l’exposé du problème.

[mgl]

Par la suite, j’aurais voulu faire une macro pour l’ajustement automatique de toutes les hauteurs de lignes de tous les tableaux d’un rapport mais cela ne me semble pas envisageable avec des tableaux si mal ordonnés. D’où l’intérêt de résoudre ce problème.

Je ne vois pas, dans la documentation, la possibilité d’intégrer un sous-rapport dans un rapport. Peut-être ai-je mal lu. Cela pourrait peut-être aider LibreOffice à produire des tableaux mieux agencés.

[mgl]

Bonjour Pierre-Yves,

Merci beaucoup pour cette fructueuse assistance,

Je commente en plusieurs fois pour contourner la limitation des 1000 caractères.

Les champs affichant des données étaient déjà des zones de texte. La seule différence avec la version que tu proposes est que j’avais modifié leurs noms : par défaut, elles s’appelle “Champ formaté” et je leur avais donné le nom de leur donnée. Ces noms étaient uniques vu que les noms des étiquettes sont du type “Champ d’étiquetteDétails” pour l’étiquette Détail.

J’ai donc renommé les zones de texte avec “Champ formaté” mais cela n’a pas résolu le problème.

Pour la hauteur automatique, le résultat me convient dans la base Bidon : la hauteur de chaque ligne du rapport ne dépend que de la longueur de la donnée ; elle peut être plus petite ou plus grande que la valeur du champs Hauteur. A noter que la propriété “Agrandissement automatique” n’apparaît pas dans la documentation.[…]

[mgl]

[…] La modification du paramètre dans la base initiale produit le même résultat mais il existe toujours trois lignes surnuméraires et vides, ajoutées entre chaque ligne “intéressante” du rapport.

Je suppose que le rapport est corrompu et qu’il est nécessaire d’effacer le contenu de la zone de Détail et de la recréer entièrement. Ce que je fais mais j’obtiens toujours une ligne surnuméraire sous chaque ligne de données, sauf pour le premier champ “Numéro” qui occupe. Le paramétrage des zones de texte est “Agrandissement automatique”, avec une hauteur de 0,5cm et une police en 9 points, la hauteur de ligne est de 0,5cm. Mais la ligne surnuméraire contient des champs en 12 points. J’essaye une étape intermédiaire en effaçant toutes les zones de texte de la zone Détail : j’obtiens encore 119 lignes lignes vides en 12 points à la place de la partie Détail.
J’ai alors recommencé en sauvegardant le rapport après l’effacement complet de la zone Détail et cela a fonctionné! […]

[mgl]

[…] L’enregistrement intermédiaire semble indispensable!

Concernant l’intégrité référentielle : 1) elle me semble complète entre la table Historique et la table Types_Evénements : 21 types existent dans la dernière qui sont tous repris dans la première; 2) elle me semble aussi complète entre la table Coordonnées et la table Historique car toutes les centrales de la première apparaissent au moins une fois dans la deuxième table et qu’aucune autre centrale n’existe dans la table Historique.

Par exemple, la requête de création de la table Type_Evénements est CREATE TABLE “Types_Evénements” (“Type” VARCHAR(30),“ID” INTEGER PRIMARY KEY).

Ne voudrais tu pas plutôt me suggérer de créer des index pour accélérer le traitement des requêtes ? […]

[mgl]

[…] Les liaisons entre les tables sont définies dans les requêtes. Par exemple : FROM “Coordonnées” LEFT OUTER JOIN “Economie” ON “Coordonnées”.“Numéro” = “Economie”.“N” : i) Je n’aime pas les liaisons implicites, ii) je préfère réserver les clauses WHERE aux “vrais” filtres.

Merci de détailler
Très cordialement
Michel

[PYS]

Bonjour @mgl

J’ai trouvé comment faire fonctionner normalement le rapport : remplacer les champs concernés par des zones de texte.
Je n’ai pas l’explication…

Pour la hauteur automatique, si je comprends bien la question, il suffit de définir le champ Détails en agrandissement automatique comme dans le fichier joint.

Bidon_CR_20200724_pys.odb

Hors sujet : mon conseil serait de définir les relations entre les tables car ceci créera des champs d’index sur les clés externes et pourrait améliorer les performances. Par ailleurs, justement, certaines données ne respectent pas l’intégrité référentielle (ne permettent pas la liaison) entre Coordonnées et Historique et entre Historique et Types_événements. Il sera nécessaire de régler cela avant de pouvoir définir les relations.

[Ajout 28-07-20 09:15]

@mgl a écrit:

Les champs affichant des données étaient déjà des zones de texte. La seule différence avec la version que tu proposes est que j’avais modifié leurs noms

Non : le dysfonctionnement vient des zones insérées soit via l’assistant lors de la création du rapport, soit d’un glisser déposer depuis la liste des champs. Il m’a suffit de supprimer ces zones et créer des zones de texte via l’outil ad hoc pour avoir le fonctionnement normal. Le rapport n’était pas corrompu et il ne m’a pas été nécessaire de supprimer la section détail.

@mgl a écrit:

Concernant l’intégrité référentielle : 1) elle me semble complète entre la table Historique et la table Types_Evénements

Les champs ne sont pas de même type (VARCHAR et INTEGER)

@mgl a écrit:

2. elle me semble aussi complète entre la table Coordonnées et la table Historique car toutes les centrales de la première apparaissent au moins une fois dans la deuxième table et qu’aucune autre centrale n’existe dans la table Historique.

Ce n’est pourtant pas ce que donne la requête suivante :

SELECT "Numéro" FROM "Coordonnées" WHERE "Numéro" NOT IN (SELECT "N_Centrale" FROM "Historique")

Cordialement

[mgl]

Bonjour Pierre-Yves
Merci pour ces compléments.
J’ai uniformisé le type de champ à INTEGER pour les compteurs des 2 tables.

Par contre, les numéros en 9000 sont des faux numéros. Les supprimer serait possible si je transférais tout le processus sur BASE alors que l’essentiel des calculs est fait dans un classeur, accessible à plus de partenaires (BASE ne sert qu’à la création des rapports et à la saisie de l’historique par mézigue). Les données sont ensuite copiées du classeur vers BASE. Je ne me sens pas le courage de transférer tous les calculs vers BASE.

Merci encore. Très cordialement Michel