[Issue]Plantage sur Modif Report accumulation champ d'un groupe

[Frankygir]

Bonjour

J'ai 3 rapports dans ma base avec à chaque fois un groupe et en bas de groupe une fonction Accumulation
J'ai aussi cette fonction accumulation en bas de rapport (je n'ai pas groupé par Année puisque ma requête ne sélectionne qu'une année) mais je n'ai aucun problème dessus

Sur le premier rapport "Débit-Crédit par moins joint" aucun problème avec la fonction accumulation de groupe alors que la fonction SQL est super compliquée

MAIS sur les deux rapports Dépenses et Recettes quand j'ai voulu mettre cette fonction, le système part en vrille, on entend le disque tourner et puis au bout d'un certain temps
soit ça plante et la base est irrécupérable
soit ça plante et la base est récupérable
soit ça met la fonction accumulation en place et le rapport fonctionne correctement mais si je veux regarder ou déplacer ce champ... c'est reparti comme avant! Sur l'image on voit qu'il ne veut pas afficher Données + fonction + Accumulation et il tourne un certain temps

Plantage oo Acc Groupe.jpg

Cela ne me semble pas dû à la structure de la table résultat de la requête relativement simple (alors que la requête est plus compliquée)

J'ai souvent perdu ma base lors de la mise au point de ces rapports. J'ai donc pris la saine habitude de sauvegarder la base juste avant de toucher ce genre de champ. D'autre part en ayant marre de devoir refabriquer les rapports quand la base plantait j'ai mis tous les changements de libellés dans la requête SQL, c'était déjà ça! et je ne touchais pas à ce champ "miné" que quand mon rapport me plaisait. Alors je tentais le coup de mettre la fonction Accumulation et je laissais le PC tourner longtemps en ayant un peur pour mon disque jusqu'à ce que ça s'arrête ; j'enregistrais et si le rapport fonctionnait j'étais content.
mais plus tard si j'avais le malheur de vouloir déplacer ce champ pour l'aligner verticalement c'était reparti pour un tour.

Pour voir le problème vous pouvez utiliser ma base d'essai

GFA_XXXXXX_Compta-2.odb

Autrement une remarque pour les rapports proposés qui nécessitait de tout recommencer ce qui suit quand la base plantait :
celui qui a conçu le rapport de base ne fait pas d'empathie mais est très fier de lui : il met les champs descriptifs de SON rapport en gras... et nos données en maigre!!!!
Cela m'a un peu déçu! C'est souvent que les gens de l'assurance-qualité de mon entreprise commettait cette faute de modestie en créant des rapports.
Résultat si tu posais sur une table côte à côte 3 rapports sur 3 questions différentes tu ne voyais pas d'un coup d'oeil lequel tu voulais
en mettant en gras le contenu et le formulaire en maigre cela sautait aux yeux
En plus il met le libellé des champs en haut de groupe et pas en haut de page donc à chaque fois il faut tout déplacer, changer le gras en maigre et inversement...

Tout cela contrairement à Works...
que j'ai quitté pour obsolescence et surtout pour avoir un vrai formulaire liant les images des relevés bancaires, pour avoir une saisie assistée par des menus déroulants, pour avoir une gestion de la clef par macro de 10 en 10 ou de 1 en 1 structurée YY ### # (ce qui m'oblige dans les rapports à déclarer un formatage ##\ ###\ # pour cette clef) et enfin pour avoir des rapports utilisant des requêtes SQL intelligentes.
Je ne regrette pas la migration mais je m'étonne de ces plantages bizarres

Peut-on déposer une demande d'amélioration à ce sujet d'initialisation des rapports?
C'est sûrement moins compliqué que de vouloir régler ce plantage qui mérite aussi de déclarer un bug

[jeanmimi]

Bonjour,
L'erreur vient de la Requête. Elle cherche une année 1 qui n'existe pas. Si je remplace 1 par 2024, la requête fait correctement l'affichage du résultat.
Ensuite, une fois cette modification effectuée, le Rapport est correct.
Pour le titre de ton message, tu peux supprimer [Base][Sun Report] puisqu'il n'y a pas de Macro en cause dans ta question et que les questions sur le Rapport dans cette section ne demandent pas un balisage.

[Frankygir]

J'ai dû mal m'exprimer
J'ai téléchargé votre base modifiée. Le système boucle encore quand je pointe le champ accumulation

Je n'ai jamais dit que ces rapports ne marchaient pas (sauf si quand il me demande une année je réponds 1 donc une année qui n'existe pas mais c'est normal mais si je réponds 2024 il marche)

Je dis qu'en mode "modification de rapport" vouloir toucher le champ Accumulation faisait partir le système en vrille.... puis au bout d'un certain temps la fonction Accumulation apparaissait mais avec un truc bizarre dedans (pas ce que je voulais demander)
néanmoins après cela le rapport fonctionnait sans problème, l'accumulation était bonne
mais si je voulais demander en mode modification ce qu'il y avait dans ce champ OO partait en vrille

Dans la requête la condition WHERE ANNEE = :ANNEE marche parfaitement sur tous les autres rapports
et en particulier dans le rapport DébitCréditparmoisjoint
où il y a deux fonctions Accumulation en pied de groupe et où je n'ai pas ce problème de départ en vrille quand je clique dessus
et où les fonctions demandées sont correctes

Bug absent sur ce rapport.jpg

Alors quel est mon problème?
-> sur le rapport Dépenses j'ai voulu demander la même chose que sur le rapport du dessus
Mais en fait si je lui demande ce qu'il a mis
il freeze

Bug non corrigé.jpg

puis ensuite je vois l'onglet Données apparaître, je clique dessus et il refreeze

Bug non corrigé 2.jpg

je patiente et je vois des trucs bizarres (mais qui fonctionnent pourtant puisque votre rapport a marché)
La programmation du champ n'est pas ce que je voulais mettre, à savoir :
Type de champ : Fonction
champ :[Montant]
Fonction : Accumulation
étendue au : Groupe

Mais :
Type de champ : Fonction définie par l'utilisateur
champ en grisé <vide>
Fonction : [AccumulationMontantTYP_DEP... ????????
étendue en grisé<vide>

Si pour vous montrer, j'essaye dans le pied de groupe de remettre un nouveau champ [Montant] en supprimant l'ancien
puis de demander dessus :
- Fonction
- Champ : [Montant]
- Fonction : il freeze sur le menu déroulant!!!!!! c'est là le BUG!!!!


et puis après un certain temps me remet les mêmes infos bizarres qui pourtant font un rapport qui marche mais qu'on ne peut modifier sans freezer
Cette fois -ci c'est :
- Typede champ de données : Fonction
- champ : [AccumulationMontantTYP_DEP]
<vide>
<vide>

C'est vraiment très bizarre

et dans le navigateur il n'indique plus:
champFormatté [AccumulationMontantTYP_DEP]
mais :
Montant : [AccumulationMontantTYP_DEP]


Tout ce que je raconte sur le rapport Dépenses est identique sur le rapport Recettes

(((((( j'ai des problèmes internet ou limitation du forum je ne peux plus envoyer d'images)))))

[jeanmimi]

Je n'ai pas de difficulté avec le Rapport :

Rapport Débit Crédit.odt

Quant aux "blocages pour les copies d'écran", c'est parce que tu es limité à 3 images par post.

[Frankygir]

Je n'ai pas de difficulté avec le Rapport :
Rapport Débit Crédit.odt

bien sûr que ce rapport marche et qu'il n'y a pas de problème avec les Accumulations quand on modifie le rapport
c'est ce que j'ai toujours dit

Ce que je voudrais c'est que ce soit aussi simple avec les rapports Dépenses et Recettes
Sur lequel il y a 2 FREEZE quand je veux voir ou déplacer le champ Accumulation
sur lesquels il y a un BUG puisque il ne met pas une fonction accumulation normale (comme dans le rapport débit-Crédit

Bug non corrigé 3.jpg

qui n'est pas ce que j'attends

Je vous montre ce qui se passe quand je veux rajouter un champ accumulation de Groupe dans un rapport Dépenses (idem pour Recettes)

Bug non corrigé 456.jpg

et là vos constaterez que je n'ai pas exactement la même formulation que sur la photo précédente
mais toujours rien à voir avec la formulation quand je demande une accumulation dans le rapport DébitCrédit
et si je reviens modifier le rapport ça va encore freezer

Dans les 2 cas c'est des nombres résultat de de equêtes qui ne sont formattés monétaires que dans le rapport

je me doute bien qu'il fait une requête SQL pour calculer cette accumulation de groupe et il doit fabriquer quelque part dans cette requête un champ nommé [AccumulationMontantTYP_DEP] mais il ne fait pas apparaître ce genre de chose dans le fameux rapport DébiCréditparmois

[jeanmimi]

Si ce que tu désires avoir un champ d'accumulation étendu au Groupe, il faut qu'il soit dans le Pied de page de Groupe ; si tu veux un champ d'accumulation étendu au Rapport, il faut qu'il soit dans le Pied de page de Rapport.
Pour insérer le contrôle qui va afficher le contenu du champ des données, tu peux aussi passer par le Menu Insertion, ce qui peut être plus stable que de le tracer à la souris sur le Rapport.

[Frankygir]

Le champ accumulation de groupe qui freeze en modif est bien dans le pied de groupe TYP_DEP
et celui qui est en pied de rapport ne pose aucun problème pour faire son Accumulation

Nota je n'ai pas groupé par année puisque ma requête ne travaillait que sur une année. J'ai donc mis son total dans le pied de rapport

[jeanmimi]

J'ai inséré le contrôle par le Menu > Insertion afin d'éviter le freeze que tu avais noté lors de son insertion. Sas doute que, lors de son insertion, ce contrôle lance le calcul du total qui s'affichera ensuite.

[Frankygir]

Bonjour

Je ne vois pas comment tu as fait
Dans le menu > insertion je n'ai que

Menu Insertion.jpg

sinon j'insère un nouveai champ Montant puis avec ce menu je demande Propriétés et quand je veux sélectionner Accumulation çà tourne en boucle

La requête avec une année n'est pas bien longue
et si on oublie de fixer une année c'est encore plus court

Donc peut-on déclarer un bug?

[jeanmimi]

Dans le menu > insertion je n'ai que

Il faut cliquer sur Zone de texte, comme dans ma copie d'écran, puis tracer ce contrôle dasns la Zone Pied de Page de Groupe du Rapport.

Donc peut-on déclarer un bug?

En recherchant dans Bugzilla, j'ai vu que le bug avait déjà été déclaré :
https://bugs.documentfoundation.org/sho ... ?id=152782

Par contre, il n'a pas été documenté pour Windows 11. C'est ce que tu auras à faire après t'être inscrit et avoir lu les commentaires des déclarants du bug.

[Frankygir]

J'ai fait ce que tu m'as dit
Menu > Insertion > champ de texte
Je l'ai mis en pied du groupe sur TYP_DEP
et dans son onglet Données j'ai rempli :
Type de Champ de Données : Fonction
Champ de Données : [Montant]
Fonction : Accumulation ==========> freeze un certain temps
=================> puis bizarrement :
l'onglet Données affiche:
Type de champ de Données : Fonction
Champ de données : [AccumulationMontantTYP_DEP]
Fonction : vide
Etendue : vide

Le calcul fonctionne mais si je touche le champ pour le déplacer ça freeze

Quant au bug que tu me signales, il est déclaré est sur
Libre Office
produit : BASE ??????
mais en fait ce devrait être sur l'extension Sun Report Builder?

Dans Bugzilla dans la liste des produits on voit LibreOffice et pas OpenOffice? ni Sun Report Builder?

[jeanmimi]

Le calcul fonctionne, mais si je touche le champ pour le déplacer ça freeze

Peux-tu vérifier si, en modifiant les coordonnées X et Y dans le volet Propriétés, tu reprends plus facilement la main après un éventuel freeze ?

Dans Bugzilla dans la liste des produits on voit LibreOffice et pas OpenOffice? ni Sun Report Builder?

Pour le bug, tu as raison, j'ai fait une erreur.
Les bugs ou bogues, pour AOO se déclarent en te reportant à l'adresse indiquée ici :
ftopic716.html

En formulant une recherche, je trouve cette notification ancienne, insuffisamment documentée selon le développeur :
https://bz.apache.org/ooo/show_bug.cgi?id=118074
En posant la question de Recherche différemment, il y a peut-être des signalements plus récents.

[Frankygir]

je me suis inscrit et j'ai déclaré un bug MAJOR (car le rapport fonctionne mais il ne faut pas avoir peur d'un freeze de 10 minutes quand on le crée ou le modifie)
mais je ne sais pas comment s'appelle la fonction Accumulation dans la version anglaise. Est-ce Cumulation?
peut-on changer pour un seul projet sur mon PC la langue?

[Oukcha]

Bonjour,

peut-on changer pour un seul projet sur mon PC la langue?

Merci de créer un fil de discussion spécifique pour cette question en
Installation et configuration.

Cordialement

[rollmops]

Bonjour,

Je reproduis la lenteur sur votre fichier.

Mais si je fais le test sur une de mes bases. Je n'ai pas le phénomène sur le rapport que je crée.

Je pense donc que c'est votre ODB qui est la source du problème.

[Frankygir]

Bonjour,

Je reproduis la lenteur sur votre fichier.

Mais si je fais le test sur une de mes bases. Je n'ai pas le phénomène sur le rapport que je crée.

Je pense donc que c'est votre ODB qui est la source du problème.

Bonjour

Merci d'avoir essayé.

Dans ma base j'ai un rapport qui utilise la fonction accumulation et qui marche parfaitement, ce qui me permet de savoir comment cela devrait marcher.
Et deux autres Dépenses et Recettes qui ont le problème du freeze.

J'ai même essayé d'en recréer un autre qui utilisait la même requête, cela n'a rien changé. Et la requête en SQL n'a pas l'air sorcier. Mais j'y ai glissé les renommages de champs (car avec le freeze je perdais parfois mon rapport et il fallait tout recommencer), et les tris car il y a un autre bug : l'outil générateur de rapport ne sait pas appliquer les tris demandés. Je lui amène donc une table déjà triée suivant le groupe demandé et les tris secondaires souhaités pour qu'il n'ait rien à faire.

En fin de compte ces deux rapports vont faire le calcul demandé mais je ne peux vouloir changer la position du champ accumulation sans repartir en freeze

[rollmops]

Re,

J'ai même essayé d'en recréer un autre qui utilisait la même requête, cela n'a rien changé.

Comme je vous l'ai dit, je ne reproduis pas sur mon ODB et qui comporte une table avec un millier d'enregistrements.
C'est peut-être la requête ou la table qui pose le problème.
Il faudrait refaire des tests en partant de zéro.

Désolé mais je n'ai pas le temps de faire des essais sur ce qui pourrait provoquer le gel temporaire sur ce type de champs.

[Frankygir]

On vous l'a déjà signalé. Quand vous répondez, veillez à ne garder que l'essentiel et ne pas citer l'intégralité du message précédent.
Surtout si c'est pour répéter encore vos propres propos. Cela alourdit inutilement la lecture.

Re,

J'ai même essayé d'en recréer un autre qui utilisait la même requête, cela n'a rien changé.

Comme je vous l'ai dit, je ne reproduis pas sur mon ODB et qui comporte une table avec un millier d'enregistrements.
C'est peut-être la requête ou la table qui pose le problème.
Il faudrait refaire des tests en partant de zéro.

Désolé mais je n'ai pas le temps de faire des essais sur ce qui pourrait provoquer le gel temporaire sur ce type de champs.

Merci mais c'est totalement inutile! Seul un développeur en regardant les sources et ayant des outils d'inspection de ma base peut trouver la faille.
Je ne crois pas que ce soit ma base car qu début en tmbant sur ce freeze j'ai fait Ctrl Alt Suppr et j'ai perdu ma base.
Je l'ai donc recréée à partir de rien. Et j'ai terminé les rapports en omettant le champ qui fait planter.
J'ai sauvegardé puis j'ai mis le champ, freeze... Patience! vérif du rapport et son cumul de groupe, sauvegarde de la base
Même démarche pour l'autre rapport, sauvegarde.

Ce bug n'est pas résolu mais il est CONTOURNABLE et il n'affecte après tout que 2 rapports sur trois
Il suffit d'être patient, de ne pas avoir peur d'un crash disque pendant le freeze car le disque dur tourne très vite!... et quand on reprend la main le cumul de groupe dans le rapport marche.

J'utilise opérationnellement avec plaisir ma base pour les enregistrements de l'année 2025 malgré d'autres bugs contournables...

[Oukcha]

je me suis inscrit et j'ai déclaré un bug

Dans ce cas, merci de copier le lien vers votre déclaration de bogue, je le fais pour vous cette fois-ci :
https://bz.apache.org/ooo/show_bug.cgi?id=128610

Notez que l'outil de report de bogue permet de voter pour les issues permettant d'accélérer la résolution d'un problème, merci de relire viewtopic.php?f=29&t=716

Il vous reste à baliser ce fil avec l'icône et la balise [Issue].

Cordialement