Différences SQL entre OOo 3.2 et LibO 3.3

fr-users
#1

Bonjour ;

Je n'ai pas la réponse à la question de Samuel à propos d'une source
ODBC sous Vista, mais sa question m'a amené à vérifier le fonctionnement
de LibO Base dans un environnement XP / MySQL / My ODBC Connector. Il
semble qu'une instruction SQL en mode natif ait du mal à être
interprétée normalement par le moteur de LibO dès lors qu'une jointure
naturelle est réalisée. J'm'explique :

Soit une base comprenant (entre autres) une table "cheval" et une table
"proprietaire". Pas de relation définie.
Soit la requête test suivante (je retape, ce n'est pas du copier/coller,
j'ai supprimé les ``) :

SELECT cheval.*, nom_prop
    FROM cheval, proprietaire
    WHERE cheval.id_prop = proprietaire.id_prop

La base comprend 200 enregistrements. En mode natif, on obtient 200 fois
les données du premier enregistrement de la base, en mode "exécution
directe de l'instruction SQL", la requête renvoie correctement les données.

La même requête (aucune modification, copiée/collée, cette fois...),
sous OOo 3.2 et précédentes, répond normalement dans les deux cas.

Le seul problème que j'avais relevé venait sous ces versions de
l'impossibilité d'utiliser une requête en mode SQL direct pour fusionner
les données d'une base avec un document texte par exemple. Il semble en
revanche, d'après les premiers tests que je viens de faire, que cette
limitation ne soit plus de mise sous LibO. Il faudra que je le confirme
par des essais un peu plus poussés, mais c'est déjà une bonne chose : le
mode "direct SQL" est important pour moi, pour diverses raisons.

Il y a par contre un truc assez énervant qui n'a pas été résolu, le fait
qu'un document de fusion ne conserve pas le lien avec la table/requête
qui lui sert de source d'entrée entre la création du document et
l'impression. On est obligé de repréciser à chaque fois quelle est la
source de données au moment de lancer l'impression. Qu'on puisse la
modifier à ce moment-là, pourquoi pas, mais LibO pourrait proposer par
défaut la source qui a servi à la création du document de fusion.

Je ne sais pas si c'est le bon endroit pour faire remonter ces infos, je
suppose que tout cela se met en place et que ça demande du temps. En
attendant, si ma contribution peut être un petit caillou dans la
construction de l'édifice, tant mieux !

M. Romano

#2

Bonjour ;

Je n'ai pas la réponse à la question de Samuel à propos d'une source
ODBC sous Vista, mais sa question m'a amené à vérifier le fonctionnement
de LibO Base dans un environnement XP / MySQL / My ODBC Connector. Il
semble qu'une instruction SQL en mode natif ait du mal à être
interprétée normalement par le moteur de LibO dès lors qu'une jointure
naturelle est réalisée. J'm'explique :

Soit une base comprenant (entre autres) une table "cheval" et une table
"proprietaire". Pas de relation définie.
Soit la requête test suivante (je retape, ce n'est pas du copier/coller,
j'ai supprimé les ``) :

SELECT cheval.*, nom_prop
    FROM cheval, proprietaire
    WHERE cheval.id_prop = proprietaire.id_prop

La base comprend 200 enregistrements. En mode natif, on obtient 200 fois
les données du premier enregistrement de la base, en mode "exécution
directe de l'instruction SQL", la requête renvoie correctement les données.

La même requête (aucune modification, copiée/collée, cette fois...),
sous OOo 3.2 et précédentes, répond normalement dans les deux cas.

Le seul problème que j'avais relevé venait sous ces versions de
l'impossibilité d'utiliser une requête en mode SQL direct pour fusionner
les données d'une base avec un document texte par exemple. Il semble en
revanche, d'après les premiers tests que je viens de faire, que cette
limitation ne soit plus de mise sous LibO. Il faudra que je le confirme
par des essais un peu plus poussés, mais c'est déjà une bonne chose : le
mode "direct SQL" est important pour moi, pour diverses raisons.

Il y a par contre un truc assez énervant qui n'a pas été résolu, le fait
qu'un document de fusion ne conserve pas le lien avec la table/requête
qui lui sert de source d'entrée entre la création du document et
l'impression. On est obligé de repréciser à chaque fois quelle est la
source de données au moment de lancer l'impression. Qu'on puisse la
modifier à ce moment-là, pourquoi pas, mais LibO pourrait proposer par
défaut la source qui a servi à la création du document de fusion.

Je ne sais pas si c'est le bon endroit pour faire remonter ces infos, je
suppose que tout cela se met en place et que ça demande du temps. En
attendant, si ma contribution peut être un petit caillou dans la
construction de l'édifice, tant mieux !

M. Romano

Bonjour,
Ce qui est un peu difficile, c'est que tu compares une version LibO non validée ni stabilisée, ce qui est le cas de LibO 3.3
avec une version de production OOo 3.2
J'ai l'impression que les comparaisons seront plus argumentées lorsque la version définitive sera proposée.
Qu'en penses-tu ?
J.M

#3

Bonjour,

Ce qui est un peu difficile, c'est que tu compares une version LibO
non validée ni stabilisée, ce qui est le cas de LibO 3.3
avec une version de production OOo 3.2
J'ai l'impression que les comparaisons seront plus argumentées lorsque
la version définitive sera proposée.
Qu'en penses-tu ?
J.M

Je ne critique pas ni ne cherche à comparer. Je fais remonter quelque
chose qui ressemble beaucoup à un bogue : la réponse de LibO à une
requête simple, qui ne présente aucune erreur de conception logique par
rapport aux normes SQL. On peut remplacer le test fait sous OOo 3.2 par
un test avec un utilitaire d'interface vers MySQL, comme PHPMyAdmin,
MyDB Studio, HeidiSQL. Le résultat est le même : la requête fonctionne,
sauf sous LibO.

J'utilise cette base de données dans le cadre de l'apprentissage de SQL
par des BTS CGO. Il est évident que je continuerai, pour l'instant, à le
faire sous OOo 3.2 : je ne peux pas lancer dans le grand bain une
version non stabilisée, mais ça ne m'empêche pas de la tester.

Mon dernier paragraphe est une suggestion d'amélioration. J'aurais dû en
faire un message indépendant, ç'aurait été plus clair.

En ce qui concerne la comparaison entre les deux versions, elle sera
faite, évidemment, mais bien entendu en comparant ce qui est comparable,
c'est-à-dire des versions stables. Il ne me viendrait pas à l'idée une
seule seconde de juger à partir d'une version en cours de développement,
je te rassure.

Cordialement ;
MR

#4

Bonjour,
  

Ce qui est un peu difficile, c'est que tu compares une version LibO
non validée ni stabilisée, ce qui est le cas de LibO 3.3
avec une version de production OOo 3.2
J'ai l'impression que les comparaisons seront plus argumentées lorsque
la version définitive sera proposée.
Qu'en penses-tu ?
J.M
    
Je ne critique pas ni ne cherche à comparer. Je fais remonter quelque
chose qui ressemble beaucoup à un bogue : la réponse de LibO à une
requête simple, qui ne présente aucune erreur de conception logique par
rapport aux normes SQL. On peut remplacer le test fait sous OOo 3.2 par
un test avec un utilitaire d'interface vers MySQL, comme PHPMyAdmin, MyDB Studio, HeidiSQL. Le résultat est le même : la requête fonctionne,
sauf sous LibO.

J'utilise cette base de données dans le cadre de l'apprentissage de SQL
par des BTS CGO. Il est évident que je continuerai, pour l'instant, à le
faire sous OOo 3.2 : je ne peux pas lancer dans le grand bain une
version non stabilisée, mais ça ne m'empêche pas de la tester.
  

Tout à fait de ton avis.

Mon dernier paragraphe est une suggestion d'amélioration. J'aurais dû en
faire un message indépendant, ç'aurait été plus clair.

En ce qui concerne la comparaison entre les deux versions, elle sera
faite, évidemment, mais bien entendu en comparant ce qui est comparable,
c'est-à-dire des versions stables. Il ne me viendrait pas à l'idée une
seule seconde de juger à partir d'une version en cours de développement,
je te rassure.

Cordialement ;
MR

Comme il y a actuellement une centaine de bugs répertoriés, tu peux regarder si celui que tu décris a été signalé.
https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=open&product=LibreOffice&content=
Je n'en ai trouvé qu'un seul portant sur les commandes SQL :
SQL "CAST" function won't work on MySQL backend
Il faut sans doute s'inscrire pour consulter le contenu.
J.M

#5

Pas besoin de s'inscrire pour consulter le détail, a priori, mais il
faut l'être pour poster un nouveau bug.

Celui que je signale n'est pas répertorié mais pour en faire un bug
complet, il faudrait pousser les tests dans d'autres environnements, ce
que je n'ai pas les moyens (ni le temps, malheureusement) de faire.

MR

#6

Bonjour,

La remarque de Marc, me parait justifiée... Je ne pense pas qu'il ait voulu critiquer pour critiquer, mais qu'il fait une critique constructive !
Je pense qu'il est utile de faire les comparaisons avant que ne sorte la version définitive, c'est à cela que sert les versions bêta !

Personnellement je n'ai pas encore installé la version bêta, mais je vais le faire d'ici peu.. Et l'idéal, à mon avis, serait de pouvoir remplacer la version de OOo que j'utilise pour le moment par la future version stable de LiBo sans rien perdre au niveau des fonctionnalités, et ne pas être obligé de continuer avec deux programmes différents installés.

Bruno Dumas