SRB (ORB)

fr-users
#1

Bonjour,
Je ne reproduis pas ce qui est décrit avec LibO 4.0.1 : le rapport fonctionne correctement pour cette fonction.
Quant à la documentation du Guide du Rapport, elle est dans la FAQ de Base.
JM

Claude FRICARD <fricard.claude@wanadoo.fr> a écrit :

#2

Je vais essayer de créer le rapport sans l'assistant , afin de vérifier que le problème provient effectivement de SRB. Je redis que je n'avais pas ce problème en 3.5.4 donc il y aune régression en 3.6.5
A+ pour un CR de mes essais.

Claude

#3

Bonjour,
je reviens au problème avec ORB, à savoir: impossibilité de créer la fonction accumulation dans le pied de groupe. Je rappelle que ce souci est apparu avec la version 3.6.5 de LibO Base. J'essaye de trouver dans quel contexte cette anomalie (euphémisme ...) survient. Le système réagit par un "plantage" de l'application, qui conduit à "tuer" la tâche soffice.bin pour reprendre la main. ORB est en cause cela a été dit par plusieurs intervenants. Toutefois lorsque je reprends une base créée sous 3.5.4 et que j'essaye de créer un champ de fonction accumulation, dans les mêmes conditions que décrites précédemment cela fonctionne ! J'ai supposé que la structure de ma base : type de relations entre tables, type de champs etc .. pouvait provoquer un environnement particulier. J'ai donc crée une nouvelle base qui reprend la structure de celle pour laquelle je n'ai pas de soucis, mais: "catastrophic error finish ... ".
Je donne ces explications pour les développeurs. A titre personnel je n'ai pas de besoin impératif de cette fonction mais les choses peuvent-elles rester ainsi ? La version 3.6.5 est la version recommandée donc à priori "fiable" , quand bien même la 4.0.1 corrigerait l'anomalie, je ne pense pas que la migration vers la version en test soit une réponse.

Claude

#4

Bonjour ;

J'utilise Base et Report Builder régulièrement, dans un environnement
d'enseignement. Les programmes des sections avec lesquelles je travaille
m'imposent l'apprentissage et l'utilisation d'un SGBDR avec un minimum de
fonctionnalités. Base remplit ces minimas, si et seulement si j'y intègre
Report Builder. J'ai donc un impératif absolu à ce que ça marche,
l'alternative étant très simple : retour à Access. Et je n'y tiens pas.

Je viens de tester ce que tu décris dans une configuration W8/64 + LibO
4.0.2.1 + Java 6u37, avec une base intégrée (HSQL) et une autre distante
sous MySQL. J'ai essayé de tester sur une "enveloppe" odb neuve et à partir
d'une autre créée en février avec une version précédente de LibO (une 3.6.5,
je pense).

Je ne reproduis pas systématiquement ton problème, ça ne m'est arrivé qu'une
seule fois, et encore s'agissait-il d'un fichier odb pas net, avec
changement de la source de données (pour gagner du temps). Je crée sans
problème des fonctions d'accumulation, soit en direct, soit en passant par
une "nouvelle fonction" et en paramétrant le cumul à la main.

Ça n'explique pas le phénomène que tu constates et ça n'apporte évidemment
pas de solution, c'est juste à titre d'information. Je mets à ta disposition
la base odb sous HSQL, tu peux la récupérer pour vérifier si le rapport
marche ou non dans ton environnement. Ça nous donnera peut-être un point de
départ pour trouver ce qui ne va pas.

Cordialement ;
Marc
nba2012_LibO_Travail.odb
<http://nabble.documentfoundation.org/file/n4047688/nba2012_LibO_Travail.odb>

#5

Bonsoir,

on peut effectivement noter que le Report Builder fait apparaître des bogues
ou des régressions qui n'existaient pas dans les versions antérieures de
LibO .
Un exemple:
- le groupement d'un champ date autre qu'en "chaque valeur" provoque un
message d'erreur; donc, impossible d'obtenir des états groupés par "mois" ou
"trimestre" etc...

Je ne rencontre pas le problème avec Report Builder sous AOo.
@+