Problème avec les sources de données d'une table de pilote

fr-users
#1

Bonjour ;

En préparant un TP sur les tables de pilote, je viens de constater
quelque chose d'assez surprenant, qui constitue me semble-t-il une
régression sérieuse en version 3.6. J'ai fouillé sur leforum j'ai trouvé
pas mal de post sur les tables de pilote mais, sauf erreur de ma part,
rien qui traite de ceproblème. Je n'ai aps trouvé non plus de bug
répertorié en faisant une recherche sur "pilot". Contexte :

  * une source de données contenant plusieurs tables (il s'agit ici de
    la liste des équipes et des joueurs du championnat NBA 2012 : on
    prend les exemples qu'on peut pour attirer le chaland, mon bon
    monsieur...) ;
  * la base de données est aux formats HSQL et MySQL (ça ne change rien
    au résultat ci-après) ;
  * cas 1 :
      o on définit comme source externe une des tables de la base de
        données (la table "joueurs") ;
      o on crée une table de pilote avec en colonne le champ "poste", en
        ligne "team" et en données moyenne du champ poids (on peut
        prendre n'importe quelle autre fonction decalcul, ça ne change
        encore rien au résultat) ;
      o on attend donc une ligne par équipe et pour chaque poste la
        moyenne de poids des joueurs évoluant à ce poste.
      o on obtient sous 3.5.4 Ubuntu le résultat attendu et sous 3.6.1
        WXP un joli effet d'escalier, assez éloigné deschiffres espérés.
  * cas 2 :
      o on extrait la table "joueurs" de la base de données et on
        l'insère dans une feuille de calcul ;
      o on refait la même table de pilote ;
      o plus aucun problème: les résultats sous 3.6.2 sont bien ceux
        attendus (et strictement identiques à ceux sous 3.5.4 source
        externe).

Je mets sur cijoint <http://cjoint.com/?0JwmlELp993>un zip qui contient
les deux classeurs "source exerne" et source interne" (je pense que les
noms sont assez explicites), ainsi que la base de données au format HSQL
pour vous permettre de reproduire sur d'autres versions de LibO.

En résumé :

- Pas de problème en version 3.5, les résultats sont identiques quelle
que soit la source de données, interne ou externe ;
- En 3.6, les résultats sont différents selon que la source est interne
ou externe, les premiers étant corrects et les seconds faux.

Cordialement ;
Marc Romano

#2

Une précision, depuis cet après-midi. Je n'avais fait le test que pour
les versions installées chez moi. J'ai refait ma manip cet après-midi
sur un poste au lycée (W7, LibO 3.5.6). Il n'y a pas de problème, le
résultat obtenu avec une source externe est bien celui attendu.

Il semble donc que ce soit un problème lié aux versions 3.6, ou en tout
cas, pour ce que j'ai pu essayé, à la 3.6.1. Reproduisez-vous sur
d'autres versions ?

Cordialement ;
Marc Romano

#3

Bonsoir Marc,
De mémoire, c'est un problème connu de la version 3.6.0/1. Normalement, je
crois qu'il est résolu avec la 3.6.3

Alex

#4

Bonjour, Alex ;

Bonsoir Marc,
De mémoire, c'est un problème connu de la version 3.6.0/1. Normalement, je
crois qu'il est résolu avec la 3.6.3

Alex

Merci pour la précision. L'information m'a échappé en fouillant le forum
et la liste des bugs. Ou alors, je n'ai pas cherché au bon endroit, ce
qui est possible.

Cordialement ;
Marc

#5

Bonjour,

J'ai fait le test avec une 3.6.2 sous Win7 64bits.

Pour moi pas de problème résultats identiques dans les 2 tableaux calcs, si
ce n'est que la mise à jour "données externes" est trèèèès lente, mais c'est
peut-être du à mon Java 7 ?

Après, à titre perso j'ai testé récemment les 2 techniques avec un lien
postgresql.

- table de pilote directement basée sur une requête

ou (j'ai un faible pour cette méthode ) :

- définir une plage de données en liaison avec une table / requête
- bâtir le / les tableaux depuis cette zone ( en trichant un peu car
impossible de créer une table de pilote basée sur une plage de données ,
seulement sur une plage nommée)

L'inconvénient de la méthode 1 est que chaque fois que l'on réouvre le
classeur calc, si on veut modifier la mise en page de la table de pilote, il
y a un appel à la requête ( et comme j'ai souvent des requêtes avec
paramètres, c'est pesant car LibO redemande, fort logiquement, les
paramètres).

Avec la méthode 2, un inconvénient : il faut actualiser la plage de données
, puis actualiser les tables de pilote
Par contre, on peut éditer la mise en page de la table de pilote sans temps
de latence du à la liaison à la base.
Et, les données dans la table de pilote ont le même format que dans la plage
de données... ce qui permet d'avoir facilement des formats numériques
différents pour des données de type entier, monétaire, etc .....

#6

Aie Aie Aie

Par contre ca ne marche pas en version 3.6.3 (testé avec la RC1 et la dev
3.6.3.0 a00d5c5)

Avec ces versions on a une régression : lors d'une actualisation ou d'une
édition de la mise en page d'une table de pilote directement liée avec une
base externe .... la table de pilote se vide de toutes ses données !!!!

J'ai testé avec les données de Marc Romano et également avec un exemple du
même genre chez moi.

Je vais aller voir si le bug est référencé.

Sinon en cas de besoin, Marc puis-je utiliser tes exemples pour la remontée
de bug ?

#7

Bonjour ;

Aie Aie Aie

Par contre ca ne marche pas en version 3.6.3 (testé avec la RC1 et la dev
3.6.3.0 a00d5c5)

Avec ces versions on a une régression : lors d'une actualisation ou d'une
édition de la mise en page d'une table de pilote directement liée avec une
base externe .... la table de pilote se vide de toutes ses données !!!!

Original ! Aïe aïe aïe en effet !

Ceci dit, en général plus le bug est gros plus il est facile à corriger.

J'ai testé avec les données de Marc Romano et également avec un exemple du
même genre chez moi.

Je vais aller voir si le bug est référencé.

Sinon en cas de besoin, Marc puis-je utiliser tes exemples pour la remontée
de bug ?

Oui, pas de problème. Je peux t'envoyer la base sous forme de script SQL
pour chargement sur un serveur si tu veux.

Cordialement ;
Marc

#8

Marc Romano wrote

Oui, pas de problème. Je peux t'envoyer la base sous forme de script SQL
pour chargement sur un serveur si tu veux.

Cordialement ;
Marc

Merci mais c'est ok avec la base en ods. J'ai eu le même comportement chez
moi avec une base en liaison avec un serveur postgresql : ok en 3.6.2 et ne
marche plus en 3.6.3.
Donc je ne pense pas que ce soit lié à la nature de la base. Le simple fait
de prendre une base comme source d'une table de pilote génère le problème.

J'avais préparé la description du bug ... du coup c'est fait :
Bug 56325 <https://bugs.freedesktop.org/show_bug.cgi?id=56325>

En espérant attirer l'attention avant la sortie officiel de la 3.6.3 ( qui
par ailleurs résout un bug important pour moi : le 31405
<https://bugs.freedesktop.org/show_bug.cgi?id=31405> )

#9

Marc Romano wrote

Oui, pas de problème. Je peux t'envoyer la base sous forme de script SQL
pour chargement sur un serveur si tu veux.

Cordialement ;
Marc

Merci mais c'est ok avec la base en ods. J'ai eu le même comportement chez
moi avec une base en liaison avec un serveur postgresql : ok en 3.6.2 et ne
marche plus en 3.6.3.
Donc je ne pense pas que ce soit lié à la nature de la base. Le simple fait
de prendre une base comme source d'une table de pilote génère le problème.

Oui, tout à fait, c'était aussi ma conclusion après avoir essayé des
bases en odb, MySQL et SQL Server (pas de postgresql pour l'instant).

J'avais préparé la description du bug ... du coup c'est fait :
Bug 56325 <https://bugs.freedesktop.org/show_bug.cgi?id=56325>

Merci de m'avoir épargné de devoir rédiger ça en anglais... :-[

Je pense que tu aurais pu, dans ton classeur, mettre une autre table de
pilote avec comme source la feuille 1. Ça montre immédiatement la
différence avec le résultat attendu.

En espérant attirer l'attention avant la sortie officiel de la 3.6.3 ( qui
par ailleurs résout un bug important pour moi : le 31405
<https://bugs.freedesktop.org/show_bug.cgi?id=31405> )

Il semble fixé, heureusement. Il me gênait aussi pas mal, mais moins que
celui des tables de pilote. Celui-là, il est bloquant en ce qui me
concerne (je comptais faire passer une partie des salles sous 3.6.3 à sa
sortie, je vais les laisser en 3.5.6 pour l'instant).

Merci de l'attention apportée à mon problème.

Cordialement ;
Marc

#10

Bonsoir,

[...]

J'avais préparé la description du bug ... du coup c'est fait :
Bug 56325 <https://bugs.freedesktop.org/show_bug.cgi?id=56325>

En espérant attirer l'attention avant la sortie officiel de la 3.6.3

Si tu veux attirer l'attention pour la 3.6.3 il faut faire vite : la RC2
est en cours de compilation, ce sera la 3.6.3 finale sauf accident. Pour
attirer l'attention il faut :
- que des utilisateurs connaissant les tables de pilote confirment le bug
- vérifier si le bug n'a pas déjà été rapporté
- ajouter le mot clé régression
- ajouter le bug à la liste des bugs les plus gênants pour la 3.6 :
fdo#44446
- en parler sur le canal irc des développeurs, urgemment s'il y a perte
de données.

Bonne soirée
JBF

#11

Bonsoir à tous,

Bonsoir,

En tout cas, cela semble fonctionner avec la Version 3.6.1.2 (Build ID: e29a214). Je vais tester à nouveau avec mon dev-build demain.

Alex

#12

Bonjour, Alexander ;

Bonsoir à tous,

Bonsoir,

En tout cas, cela semble fonctionner avec la Version 3.6.1.2 (Build
ID: e29a214). Je vais tester à nouveau avec mon dev-build demain.

Alex

Surprenant : c'est précisément avec cette version (même build) que j'ai
repéré le problème. Je confirme en revanche que le problème n'existe pas
sur les versions 3.4 et 3.5 (testé la 3.4 - vérifié en reprenant mes
fichiers "finalisés"sur le même TP fait l'an dernier - et la 3.5.6 cette
année).

Marc

#13

Jean-Baptiste Faure wrote

Bonsoir,

Si tu veux attirer l'attention pour la 3.6.3 il faut faire vite : la RC2
est en cours de compilation, ce sera la 3.6.3 finale sauf accident. Pour
attirer l'attention il faut :
- que des utilisateurs connaissant les tables de pilote confirment le bug
- vérifier si le bug n'a pas déjà été rapporté
- ajouter le mot clé régression
- ajouter le bug à la liste des bugs les plus gênants pour la 3.6 :
fdo#44446
- en parler sur le canal irc des développeurs, urgemment s'il y a perte
de données.

Bonne soirée
JBF

Merci des conseils.

J'ai donc rajouté le bug dans le bug centralisateur 44446.
Alexander a fait le test et fait le report ici et dans freedesktop, mais
comme précisé cela marche effectivement en 3.6.1. Le problème apparait dans
la 3.6.3 rc1
Si d'autres personnes sur la liste peuvent tester en 3.6.3 rc1 .....
Le mot clé "regression" apparait dans l'intitulé du bug.

J'ai rajouté Kohei Yoshida dans la liste CC car d'après mes recherches sur
freedesktop il a participé à la résolution des bugs précédents concernant
les tables de pilotes.

Quand au canal irc, je ne l'ai jamais utilisé, il faut que je creuse.

#14

Bonsoir,

Je reviens à la charge.

Si quelqu'un ( Alexander avec une version plus récente ?), voir quelques
uns, pouvai(en)t confirmer le bug 56325
<https://bugs.freedesktop.org/show_bug.cgi?id=56325> ce serait sympa.

Par contre effectivement, il n'apparait qu'à partir de la 3.6.3 rc1 ( ou
dev) ou les versions daily builds de la 3.6.4 et de la 3.7.0, donc il faut
avoir une de ces versions sur son poste.

Pour mémoire ( et sous windows) les versions "dev" s'installent
automatiquement en parallèle de la version normale (contrairement aux
versions "rc" qui remplacent la version existante). Vous pouvez donc les
tester sans interférer sur votre version "de production" , mais faites le
quand même sur des copies de vos documents de travail.

Merci !

#15

Bonjour

Nico2012 wrote

Si quelqu'un ( Alexander avec une version plus récente ?), voir quelques
uns, pouvai(en)t confirmer le
bug 56325 <https://bugs.freedesktop.org/show_bug.cgi?id=56325>
ce serait sympa.

J'ai confirmé...

Cordialement
Pierre-Yves

#16

Bonjour ;

Bonjour

Nico2012 wrote

Si quelqu'un ( Alexander avec une version plus récente ?), voir quelques
uns, pouvai(en)t confirmer le
bug 56325 <https://bugs.freedesktop.org/show_bug.cgi?id=56325>
ce serait sympa.

J'ai confirmé...

Cordialement
Pierre-Yves

Je suis quand même très surpris par l'affirmation quasi générale que
cela fonctionne en 3.6.1. Je suis en 3.6.1.2 sous XP et en 3.5.4 sous
Ubuntu, j'ai signalé initialement le problème parce que cela ne
fonctionnait pas dans la première de ces deux versions et je confirme
encore une fois qu'il est impossible d'obtenir un résultat correct. Je
ne sais vraiment pas comment vous faites pour obtenir une table de
pilote correcte en 3.6.1, toutes mes tentatives, quelle que soit la
source externe utilisée, se soldent par un résultat différent entre 3.5
et 3.6, le résultat exact étant celui de la 3.5.

Je viens de faire le même test que celui fait par Pierre-Yves. Le
résultat est correct, en effet, SI et SEULEMENT SI on se limite à _un
seul_ critère. Par contre, dès qu'on introduit DEUX critères, un en
ligne et un en colonne, ça part en n'importe quoi. Pour faire ce genre
d'analyse sur un critère, on n'a pas besoin d'une table de pilote.
Celle-ci n'est utilise qu'à partir du moment où les analyses portent sur
deux critères au moins. A la base, ça s'appelait "tableau d'analyse
_croisée_", non ?

Pour essayer de comprendre ce qui se passe, j'ai rajouté un 60e
enregistrement à la table "biblio", avec un champ "Publisher" totalement
différent de ceux existants, puis retesté sous les deux versions : le
nouvel enregistrement est correctement affecté à son éditeur en 3.5.4,
il est affecté n'importe comment en 3.6.1 (à un éditeur qui ne
correspond pas).

A propos, il semble qu'il y ait un problème avec cette base de données,
soit sous XP, sous sous 3.6.1 : elle contient normalement 59
enregistrements (elle est liée à une source de données dBase qui se
trouve dans le dossier "<app data LibO>\user\database\biblio"). Or,
lorsqu'on l'ouvre avec Base, seuls les 20 derniers enregistrements sont
apparents et traités. Ce qui explique la mention de Pierre-Yves :
"Expected result: table pilot with 10 rows, 2 columns" (normalement,
dans sa configuration de test, il devrait y avoir 29 lignes).

En recréant une base vierge et en recréant la connexion, voilà ce que je
constate :

  * la connexion est faite vers le dossier biblio délivré avec la
    version 3.6.2 sous XP : on n'accède qu'aux 20 derniers
    (physiquement, pas dans l'ordre de la clé primaire) enregistrements
    de la base
  * la connexion est faite vers le dossier biblio copié d'une version
    3.5.4 Ubuntu : ça marche, on a 59 enregistrements accessibles.

J'ai testé de manière croisée : le dossier biblio 3.6.2 transféré sous
Ubuntu => 20 enregistrements, le dossier 3.5.4 Ubuntu transféré sous XP
=> 59 enregistrements.

Conclusion : sur le premier point (les tables de pilote), ou je ne sais
plus me servir d'une table de pilote, ou il y a quelque chose qui
m'échappe complètement. Sur le deuxièle point, je ne sais pas, il
faudrait tester plus en profondeur les différentes combinaisons. Mais il
y a un problème de cohérence, ça me paraît évident.

Cordialement ;

Marc

#17

Bonjour Marc

Marc Romano wrote

Je suis quand même très surpris par l'affirmation quasi générale que
cela fonctionne en 3.6.1.

Je n'ai pas testé avec cette version (je ne l'ai pas sous la main...)

Marc Romano wrote

A propos, il semble qu'il y ait un problème avec cette base de données,
soit sous XP, sous sous 3.6.1 : elle contient normalement 59
enregistrements (elle est liée à une source de données dBase qui se
trouve dans le dossier "
<app data LibO>
\user\database\biblio"). Or,
lorsqu'on l'ouvre avec Base, seuls les 20 derniers enregistrements sont
apparents et traités

Peut-être as-tu une version issue de profils précédents car en installant
avec un profil vierge (désinstallation, suppression des répertoires,
ccleaner
avant install) je n'ai bien que 20 enregistrements dans le fichier dBase...
et donc 20 enreg. via le odb.

Toujours avec une version "vierge" il y a un filtre posé sur la table:

db:order-statement db:command="&quot;biblio&quot;.&quot;Identifier&quot;"

Ceci est le filtre par défaut mais peut-être que ta version ajoute une
sélection
(à vérifier en ouvrant la table et en supprimant le filtre) ?

Cordialement
Pierre-Yves

#18

Bonsoir ;

Bonjour Marc

Marc Romano wrote

Je suis quand même très surpris par l'affirmation quasi générale que
cela fonctionne en 3.6.1.

Je n'ai pas testé avec cette version (je ne l'ai pas sous la main...)

Je n'ai pas dit que c'était toi qui affirmais cela. J'ai parlé d'un
accord "quasi général" :

  * "Well it appears to work properly in Version 3.6.1.2 (Build ID:
    e29a214)" (Alex - même version, même build que la mienne)
  * "Yes, it's ok with 3.6.1 and 3.6.2" (Nicolas)

Or, malgré tous les tests que j'ai pu faire avec des sources
différentes, je n'ai jamais obtenu un résultat correct en 3.6.1 dès lors
qu'on croise deux critères. C'est cela que je ne comprends pas.

Marc Romano wrote

A propos, il semble qu'il y ait un problème avec cette base de données,
soit sous XP, sous sous 3.6.1 : elle contient normalement 59
enregistrements (elle est liée à une source de données dBase qui se
trouve dans le dossier "
<app data LibO>
\user\database\biblio"). Or,
lorsqu'on l'ouvre avec Base, seuls les 20 derniers enregistrements sont
apparents et traités

Peut-être as-tu une version issue de profils précédents car en installant
avec un profil vierge (désinstallation, suppression des répertoires,
ccleaner
avant install) je n'ai bien que 20 enregistrements dans le fichier dBase...
et donc 20 enreg. via le odb.

Mon profil est récent, je l'ai refait fin septembre. Ce qui me surprend,
c'est que les fichiers dBase de la version XP sont plus gros que ceux de
la version Linux, avec moins d'enregistrements. De plus, lorsque je
fouille les fichiers de la version XP, je "vois" les données visibles
sous Linux mais masquées à l'affichage par Base sous XP.

Toujours avec une version "vierge" il y a un filtre posé sur la table:

db:order-statement db:command="&quot;biblio&quot;.&quot;Identifier&quot;"

Ceci est le filtre par défaut mais peut-être que ta version ajoute une
sélection
(à vérifier en ouvrant la table et en supprimant le filtre) ?

Non, pas de filtre apparent (ou alors, je ne sais pas où le chercher).
Le paramètre que tu cites est, AMHA, simplement l'ordre de tri pour
l'affichage des lignes de la table.

Je n'ai pas de machine sur laquelle je puisse faire davantage de tests
(vais essayer de voir ça demain sur une des machines du lycée, sous W7
et 3.5.6), mais il y a quelque chose de bizarre dans cette base de données.

Cordialement ;
Marc

#19

D'abord merci à pierre-yves pour sa confirmation sur freedesktop du bug 56325

Ensuite pour marc. J'ai sans doute parlé un peu vite en évoquant la 3.6.1,
car j'ai surtout testé la 3.6.2.
Et effectivement il y avait un bug ( 53929
<https://bugs.freedesktop.org/show_bug.cgi?id=53929> ) dans la 3.6.0 et
3.6.1, résolu dans la 3.6.2.

J'étais moi même tombé sur ce bug (en 3.6.0 ou 3.6.1) ce qui m'avait fait
retourner pour un temps à la 3.5. Bug qui au demeurant se produit dans tous
les cas : liaison avec plage de cellules interne ou directement avec une
source de données.

Donc il me semble que les pivottable en 3.6 ne sont pas utilisables avant la
3.6.2. Voir même pour l'instant uniquement en 3.6.2 si on considère le bug
56325 dans le cas d'un lien direct avec une source de données, bug qui
handicape les versions 3.6.3 et supérieures.

#20

Bonjour,

[...]

J'avais préparé la description du bug ... du coup c'est fait :
Bug 56325 <https://bugs.freedesktop.org/show_bug.cgi?id=56325>

Le bug vient d'être corrigé par Kohei sur le master. Il a demandé le
backport du correctif sur la 3.6, il devrait donc être disponible dans
la 3.6.4.

Bonne journée
JBF