OpenOffice et LibreOffice

fr-users
#1

Bonjour,

Je fais partie d'une association.

J'ai créé une base de données pour gérer le fichier des adhérents avec LibreOffice Base. Etant néophite, j'étais très fière de moi et pensais naïvement peut-être que tous nos problèmes de transmissions de fichiers entre nous allaient être résolus.

Lorsque j'ai voulu passer ce fichier à une autre personne de l'association  qui avait OpenOffice sur son ordi, elle n'a pu utiliser le formulaire de saisie créé avec LibreOffice.

J'ai moi même téléchargé OpenOffice sur mon ordinateur pour avoir la possibilité de lire les fichiers de cette personne. Hélas cela a bloqué le fonctionnement de LibreOffice.

Est-ce que cela veut dire que les deux suites ne peuvent co-exister sur une même machine ? ou faut-il faire quelquechose pour pouvoir se servir des deux suites sur une seule machine sans qu'elles s'annulent l'une l'autre ?

Pour quoi ne peut-on utiliser les fichiers créés avec LibreOffice à l'aide du logiciel OpenOffice ?

Je ne suis pas très forte en informatique.

Je pensais que les logiciels libres ouvraient tous les fichiers.

Jusque là, j'utilisait une base de données très pratique et très facile à mettre en oeuvre : FileMakerPro. Pourquoi ne pas faire évoluer le module Base de données de LibreOffice de façon à ce qu'il ait la facilité d'emploi de FileMakerPro ? C'est une proposition mais je suis incapable de savoir ce que cela représente comme travail pour un informaticien patenté.

Bonne journée à tous

Marie Jo

#2

Bonjour Marie-jo,

Reste plutôt avec FMPro pour tes bases de données pour l'instant, aucune
amélioration de Base n'est prévue dans l'immédiat pour le rendre plus
"orienté-utilisateur", on a déjà assez de mal à réparer les bugs qui sont
introduits pour avancer les autres modules, et ce sans compter les vieux
bugs du temps de OOo qui reste encore à corriger. Franchement, FMPro
l'emporte haut la main si tu n'as besoin que de partager tes BDD entre
utilisateurs Windows et Mac.

Base diffère aujourd'hui entre AOO et LO, les moteurs hsqldb ne sont plus à
la même version, ce qui peut provoquer des problèmes d'ouverture, mais il y
a d'autres facteurs qui peuvent également influer, notamment les chemins de
configuration, l'existence ou non d'images stockées dans la bdd, etc. Ce
n'est pas, contrairement aux apparences et au marketing, un fichier qu'on
peut déplacer aussi facilement que ça, surtout quand il s'agit de le faire
lire par AOO. Comme on dit en anglais, YMMV (your mileage may vary), en
d'autres mots, il n'y a aucune garantie que ce qui marche chez toi, marche
aussi chez les autres...

Tout cela semble sans doute assez négatif, mais c'est la réalité que je
regarde en face - Base n'est pas, n'a jamais été, et à l'heure actuelle ne
sera jamais un produit à mettre entre les mains des "petits utilisateurs".
Si je continue à m'en servir personnellement, c'est que j'ai appris à vivre
avec ces lacunes ou tout simplement je fais avec autre chose.

Alex

#3

Bonjour Alexander,

Je te remercie de ta réponse rapide et complète.

Il y a quelques années, j'avais déjà essayé de faire un fichier des adhérents avec OpenOffice Base et après un an d'utilisation j'avais laissé tomber car je n'avais pas trouvé ce logiciel très stable. J'avais espoir qu'avec LO cela soit mieux mais apparemment non. Au fait existe-t'il quelquepart une liste des type de champs avec l'explication de chaque type de champs je n'ai pas su la trouver sur les différents didactitiels que j'ai consulté. A part Texte[varchar] ou Date ou Numérique les autres types ne sont expliqués nullepart.

Nous allons donc rester pour le moment avec FMPro qui est vraiement très facile d'emploi (j'ai quand même su me servir de LO pour créer la table et le formulaire et quelques requêtes, ce n'est pas si difficile que ça). Le seul hic c'est que notre logiciel FMPro est très vieux et que les machines deviennent de plus en plus modernes. Nous avons peur qu'un jour il ne fonctionne plus sur nos bécanes. On verra bien !

Reste aussi la solution de tenir le fichier des adhérents avec Calc mais comme j'ai beaucoup de rubriques sur une fiche d'adhérent, je ne peut utiliser la fonction Formulaire qui pourtant me semblerait bien pratique.

Merci encore de ta réponse

Bonne Journée

Marie Jo

#4

Re-bonjour,

Il y a quelques années, j'avais déjà essayé de faire un fichier des adhérents avec OpenOffice Base et après un an d'utilisation j'avais laissé tomber car je n'avais pas trouvé ce logiciel très stable. J'avais espoir qu'avec LO cela soit mieux mais apparemment non.

Les problèmes de stabilité sont toujours d'actualité, malheureusement.
Ceci ne résulte pas du choix du moteur de bdd (hsqldb), qui en soi, et
en dehors de LO/OOo est véloce, stable et assez performant, mais c'est
justement son intégration dans OOo/LO qui rend l'ensemble instable, et
disons que, cela ne s'est pas amélioré depuis la création de LO. Du côté
de AOO, la scène n'est guère plus rose, et à cause de problèmes de
licence, les développeurs ont dû enlever pas mal de fonctionnalités
liées à Base, dont le connecteur C MySQL direct, et le moteur de
rapports de bdd pentaho (le générateur de rapports appelé ORB), pour ne
nommer que ces deux-là.

Du coup, les utilisateurs de Base et de bdd libres dans une interface de
bureautique se trouvent un peu au croisé des chemins :

- continuer avec les anciennes versions de OOo, avec tous ses vieux bugs
et ses failles de sécurité ;

- choisir AOO qui, faute d'intérêt, et notamment, d'une poussée d'IBM
dans ce sens par le biais de son code Symphony, semble partir sur un
abandon à long terme d'un module Base dédié (même malgré l'intégration
d'une version plus récente de hsqldb) ;

- choisir LO, dont les fonctionnalités Base sont à peine maintenues,
pour l'heure sans, semble-t-il, de développements concrets nouveaux ou
de changements prévus, rendant Base ains de plus en plus difficile à
maintenir dans la durée face aux développements de plus en plus poussés
des autres modules de la suite.

Au fait existe-t'il quelquepart une liste des type de champs avec l'explication de chaque type de champs je n'ai pas su la trouver sur les différents didactitiels que j'ai consulté. A part Texte[varchar] ou Date ou Numérique les autres types ne sont expliqués nullepart.

A priori, la documentation de hsqldb peut être trouvée dans les fichiers
du paquet disponible ici :
http://sourceforge.net/projects/hsqldb/files/hsqldb/hsqldb_1_8_1/

En fait, elle n'est plus disponible sur le site web de hsqldb, puisque
une version plus récente du moteur est disponible, mais celle-ci ne se
retrouve pas (encore) dans LO.

Nous allons donc rester pour le moment avec FMPro qui est vraiement très facile d'emploi (j'ai quand même su me servir de LO pour créer la table et le formulaire et quelques requêtes, ce n'est pas si difficile que ça). Le seul hic c'est que notre logiciel FMPro est très vieux et que les machines deviennent de plus en plus modernes. Nous avons peur qu'un jour il ne fonctionne plus sur nos bécanes. On verra bien !

Il est vrai que si des logiciels comme FMPro (pour ma part, j'ai la
version 5.5) ou Lotus Approach continuent à tourner sur Windows OS
32bits (XP, Vista), on peut se demander légitimement pour combien de
temps encore cela va être le cas.

Reste aussi la solution de tenir le fichier des adhérents avec Calc mais comme j'ai beaucoup de rubriques sur une fiche d'adhérent, je ne peut utiliser la fonction Formulaire qui pourtant me semblerait bien pratique.

Non, Calc n'est pas vraiment adapté pour ce genre de chose (même si tout
le monde sait que les feuilles de Calcul sont souvent détournées pour
servir de base de données).

Quel est ton problème précis par rapport aux formulaires et le nombre de
champs ? Pas assez de place à l'écran pour pouvoir imprimer en A4 ou
garder la visibilité pour l'utilisateur ? C'est aussi une indication que
ta base de données monotable serait peut-être mieux organisée en
regroupant certains champs dans des tables séparées et en créant des
sous-formulaires à la place.

Alex

#5

Bonjour Alex et tous,

Re-bonjour,

[...]

En fait, elle n'est plus disponible sur le site web de hsqldb, puisque
une version plus récente du moteur est disponible, mais celle-ci ne se
retrouve pas (encore) dans LO.

Je rebondis ici pour mentionner que cette intégration avait été pour grande partie financée par la communauté et notamment le projet allemand et le projet francophone. Peut-être serait-il intéressant de mobiliser des énergies à nouveau pour faire que l'intégration soit maintenue à un niveau correcte, si cela en vaut la peine bien sûr. Je ne suis pas une grande utilisatrice de Base, mais si HSQLDB répond à une réelle demande (plutôt que HSQLite par exemple) peut être que c'est à explorer/pousser ?

À bientôt
Sophie

#6

Bonjour Sophie,

Bonjour Alex et tous,

Je rebondis ici pour mentionner que cette intégration avait été pour
grande partie financée par la communauté et notamment le projet
allemand et le projet francophone. Peut-être serait-il intéressant de
mobiliser des énergies à nouveau pour faire que l'intégration soit
maintenue à un niveau correcte, si cela en vaut la peine bien sûr. Je
ne suis pas une grande utilisatrice de Base, mais si HSQLDB répond à
une réelle demande (plutôt que HSQLite par exemple) peut être que
c'est à explorer/pousser ?

Ta question est juste, effectivement je ne sais pas, à part le fait que
le moteur hsqldb soit lui-même amélioré et plus performant, si cela
apporte une plus grande stabilité à l'utilisation de Base - la manière
dont OOo et LO gère l'accès à la mémoire et le stockage temporaire des
données avant écriture effective dans la base ayant toujours été le
talon d'Achille de l'ensemble. Il faudrait sans doute plus de retours
sur l'utilisation de AOO avec le nouveau moteur...

Si, un point important quand même : j'ai cru comprendre que les bases de
données faites avec le nouveau moteur intégré hsqldb dans AOO sont
incompatibles avec les versions précédentes de OOo et par voie de
conséquence, avec LO (je n'ai pas encore testé). Cela militerait en
effet pour son intégration dans LO, rien que pour maintenir la
compatibilité entre AOO et LO.

Alex

#7

Je ne suis pas non plus un grand utilisateur de base, mais je l'utilise pratiquement tous les jours sans utiliser des fonctions très poussées. Les rapports me sont très utiles ainsi que les requêtes qui me permettent d'effectuer des publipostages ciblés.
Le béotien que je suis ne sais pas si HSQLDB, HSQLite ou autre chose serait le plus adapté à mon usage, mais lorsqu'il ne plante pas, base me convient, et je serais contrarié de le voir s'éteindre.

@+

Hugues Bousquet

#8

News fraiches d'il y a quelques heures:

Pour info, Lionel a decouvert que sqlite n'est pas le candidat ideal car
il manque le support des dates. Il est en court de recherche d'un autre
moteur de base de donnees pour remplacer hsqldb qui ne soit pas en Java.

#9

Bonjour Hugues,

Je ne suis pas non plus un grand utilisateur de base, mais je
l'utilise pratiquement tous les jours sans utiliser des fonctions très
poussées. Les rapports me sont très utiles ainsi que les requêtes qui
me permettent d'effectuer des publipostages ciblés.
Le béotien que je suis ne sais pas si HSQLDB, HSQLite ou autre chose
serait le plus adapté à mon usage, mais lorsqu'il ne plante pas, base
me convient, et je serais contrarié de le voir s'éteindre.

Il n'est pas (encore) question de le voir supprimé de LO, mais sur les
300 (400 ??) et quelques développeurs/contributeurs que le projet se
réclame de comporter, il n'y a qu'environ 1 ou 2 qui travaillent
régulièrement sur les problèmes de Base (j'ai vu récemment 2 ou 3 autres
qui sont arrivés pour essayer de résoudre leurs cas spécifiques, mais
aucun ne concerne la partie hsqldb ou la fonctionnalité de base du module).

Le souci est que Base, c'est un panier à crabes au niveau du code
source. Il y a des choses très anciennes et dedans, du temps de
StarOffice et puis, il y a ce qu'a fait Sun lorsque Base V2 a été
développé, ce qui avec le recul correspond à avoir essayé de souder un
moteur de Porsche sous le capot d'une carrosserie de 2CV - eh bien, ca
va bien jusqu'à un certain point et puis les rotules lachent et les
roues tombent...ok, c'est imagé, mais c'est un peu ça.

Donc, ce que je veux dire c'est que, toucher au code de Base, en tant
que développeur, c'est délicat...déjà, il faut essayer de comprendre
pourquoi telle fonction a été codée de telle façon, et puis même de
comprendre ce qu'un morceau de code est supposé faire. Du coup, les
développeurs ne se pressent pas en masse pour essayer de remonter tout
ça correctement. Je vois Lionel et Julien, les deux développeurs qui
semblent actuellement les plus impliqués dans les problèmes de Base,
avancer à tâtons, de peur de faire tomber le château de cartes. C'est
donc logique qu'il n'y aura aucune grande révolution au niveau de Base
dans un avenir proche.

Pour moi, le souci vient plus de l'impact et éventuelles répercussions
que pourraient avoir les nouveaux développements de AOO, qui semblent se
pousser vers une espèce de fusion avec le code de Symphony qui,
rappelons-le, n'a pas de module de base de données spécifique. Pour IBM,
il est clair qu'un module Base, ils n'ont en rien à faire, et
heureusement il y a encore les anciens développeurs OOo (entre autres
maintenant chez IBM) qui militent encore en faveur du maintien du statut
quo de la fonctionnalité, mais il faut voir à la longue ce que cela
donnera. Même si on est des projets séparés, on voit bien qu'il y a déjà
une petite guéguerre au niveau des performances de la suite. Qu'en
serait-il pour LO, si AOO se débarassait de Base et découvrait par la
même occasion une amélioration fulgurante des performances ? Je crois
que la messe serait vite dite.

Tout ceci n'est bien entendu qu'une hypothèse parmi d'autres, j'espère
qu'on me prouvera le contraire et que Base continuera à évoluer...

Alex

#10

Bonjour Cédric,

News fraiches d'il y a quelques heures: Pour info, Lionel a decouvert
que sqlite n'est pas le candidat ideal car il manque le support des
dates. Il est en court de recherche d'un autre moteur de base de
donnees pour remplacer hsqldb qui ne soit pas en Java. -- Cedric

Oui, j'avais vu passer ce message. C'est dommage, mais réaliste, :-/

En fait, si j'ai bien compris, ça va encore plus loins que la juste la
gestion des dates, en ce que SQLite ne fait aucun typage de la plupart
des données, et du coup, les stocke dans ses structures internes sous
forme de chaînes de caractères (si je me suis exprimé correctement,
n'étant pas programmeur).

Espérons qu'une autre solution se présentera :-))

Alex

#11

Bonjour à tous ;

Pour moi, le souci vient plus de l'impact et éventuelles répercussions
que pourraient avoir les nouveaux développements de AOO, qui semblent
se pousser vers une espèce de fusion avec le code de Symphony qui,
rappelons-le, n'a pas de module de base de données spécifique. Pour
IBM, il est clair qu'un module Base, ils n'ont en rien à faire, et
heureusement il y a encore les anciens développeurs OOo (entre autres
maintenant chez IBM) qui militent encore en faveur du maintien du
statut quo de la fonctionnalité, mais il faut voir à la longue ce que
cela donnera. Même si on est des projets séparés, on voit bien qu'il y
a déjà une petite guéguerre au niveau des performances de la suite.
Qu'en serait-il pour LO, si AOO se débarassait de Base et découvrait
par la même occasion une amélioration fulgurante des performances ? Je
crois que la messe serait vite dite. Tout ceci n'est bien entendu
qu'une hypothèse parmi d'autres, j'espère qu'on me prouvera le
contraire et que Base continuera à évoluer... Alex

Si cela était le cas, Aoo serait totalement disqualifié dans le monde
l'éducation, du moins dans le secondaire et le supérieur technologique.
La présence d'un SGBDR est une nécessité imposée par les programmes.
Idem si LibO abandonnait le module Base.

Or, LibreOffice entre aujourd'hui dans les lycées en grande partie par
l'enseignement technologique, parfois par le professionnel, tous les
deux gros consommateurs de suites bureautiques. Tel qu'il existe
aujourd'hui, le module Base (plus Report Builder) constitue une
fonctionnalité suffisante pour couvrir les besoins de ces sections. Il
permet d'aborder pas mal de notions liées aux bases de données, depuis
l'étiquetage des champs jusqu'aux contraintes d'intégrité, en passant
par les notions de formulaire, de rapport, de requête en mode QBE et
SQL, et on n'en demande pas plus. Il ne permet pas de faire un
développement complet d'application (quoique, si elle est assez
simple...), mais ce n'est pas notre objectif. De plus la possibilité
d'utiliser Base en frontal vers des bases MySQL est extrêmement
intéressante, notamment dans les sections de technicien supérieur.

Vous direz que je prêche pour ma petite paroisse, et je vous l'accorde
bien volontiers. Je pense néanmoins que c'est un aspect à prendre en
compte : uniquement en ce qui concerne les établissements dont je
m'occupe, la suppression de Base entraînerait l'obligation de fait
(imposée par les programmes) de retourner vers Access, et personne ne
comprendra (ni n'admettra) qu'on ne prenne qu'Access dans la suite
Office. Et ça nous fait 400 postes et 2000 utilisateurs en moins pour
LibreOffice...

Il ne manque pas grand-chose à Base pour être une alternative valable,
du moins pour des applications simples pour une petite structure
professionnelle (je suis à peu près certain que ce que je demande à mes
étudiants de BTS est très largement au-dessus, en termes de complexité
et de fonctionnalité, de 80% des utilisations en petite entreprise, et
ce n'est pas très élaboré, croyez-moi). Il y a quelques bugs à corriger,
plus gênants que vraiment bloquants, quelques fonctionnalités à
intégrer, comme la possibilité de faire simplement des menus. HSQL est
un moteur qui n'est pas mal, même si je le trouve un peu trop chichiteux
sur le plan de la syntaxe (ça contraint les utilisateurs à de la
rigueur, ce qui n'est certes pas plus mal, mais trop chronophage).

Mon intervention ne fera pas avancer le produit malheureusement (manque
à la fois de temps et de compétences), c'est juste un avis.

Marc Romano

#12

Re,

Si cela était le cas, Aoo serait totalement disqualifié dans le monde
l'éducation, du moins dans le secondaire et le supérieur technologique.

Pour AOO, rien n'est encore décidé, mais le ORB est déjà dehors et le
connecteur mysql aussi. Ils ne pourront être réintégrés. Actuellement,
l'extension connecteur mysql direct disponible sur le site d'extensions AOO
ne fonctionne plus avec la dernière version de celui-ci, en tout cas sur
Windows, je ne sais pas ce qu'il en est pour les autres OS.

La présence d'un SGBDR est une nécessité imposée par les programmes.
Idem si LibO abandonnait le module Base.

Comme l'a dit Cédric, on cherche pour LO une autre solution pour essayer

de remplacer hsqldb. Je vois du rapport du comité de pilotage qu'il serai
question de firebird, car il existe une version distribuée en MPL, donc une
licence qui va bien. Pour avoir utilisé une bdd firebird dans une
application embarquée au niveau professionnel, je sais que c'est un moteur
tout à fait capable. Reste à voir si cela est techniquement faisable.

Mon intervention ne fera pas avancer le produit malheureusement (manque
à la fois de temps et de compétences), c'est juste un avis.

Ce genre d'avis est très important pour rappeler qu'il existe des "volume

users" de Base, qu'on se le dise ! :-))

Alex

#13

Bonsoir,

Merci pour ces précisions sur base, que j'aimerais utiliser de manière plus régulière et plus professionnelle. Il est toujours intéressant de connaitre les histoires du logiciel, et de cerner ainsi la route un peu caillouteux de StarOpenLibreApacheOffice.org. (J'étais déjà utilisateur de StarOffice à l'époche de StarDivision...).

J'ai eu une indication sur la liste DE de Robert Großkopf concernant la connexion à une base locale MySQL (que je n'ai pas encore réussi), mais j'ai d'énormes lacunes de connaissance de "base" ("fondamental" et le logiciel lui-même).

Est-ce qu'il y a des cours d'initiations pour utiliser base correctement ? Et surtout avec MySQL ? A tout hasard ?

Merci,
Martin

#14

Bonjour ;

Pour AOO, rien n'est encore décidé, mais le ORB est déjà dehors et le
connecteur mysql aussi. Ils ne pourront être réintégrés. Actuellement,
l'extension connecteur mysql direct disponible sur le site
d'extensions AOO ne fonctionne plus avec la dernière version de
celui-ci, en tout cas sur Windows, je ne sais pas ce qu'il en est pour
les autres OS.

Pour ORB (je suppose que tu veux parler de Report Builder labellisé
"Oracle"), c'est une erreur majeure, à mon avis : la disponibilité d'un
outil permettant de faire quelques calculs simples dans un rapport est
un argument déterminant pour justifier l'utilisation de LibO en lieu et
place d'Access. Lequel, sur ce point précis du générateur de rapport, a
des années-lumière d'avance. L'EN utilise majoritairement la suite
Office. Les pochettes, sujets et supports d'examen qui portent sur les
bases de données sont exclusivement conçus à partir d'exemple et de
supports Access. Lors des oraux, les examinateurs attendent que les
fonctionnalités d'Access soient reproduites. Et la génération d'un
rapport avec sous-totaux est une demande quasiment incontournable.
Bizarrement, il est très rare que soit demandé un formulaire avec
sous-formulaire (sous Access, c'est un parcours du combattant pour le
faire, sous LibO, c'est d'une facilité déconcertante).

En ce qui concerne le connecteur MySQL natif, je prie la communauté de
m'excuser, mais c'est AMHA l'exemple type du "faux problème". Je m'explique.

Il existe un connecteur ODBC fournit par MySQL qui est à la fois simple,
efficace, rapide et gratuit. Le seul intérêt de développer un connecteur
propre est l'indépendance, mais sur ce point précis je trouve que c'est
un mauvais argument : on ne va pas chercher un truc exotique, on utilise
pour accéder à une base MySQL le connecteur fournit par MySQL. Ça me
semble cohérent, tout simplement.

Pour info, c'est ce que j'ai mis en place (MySQL ODBC Connector
5.quelque chose). Je ne me sers jamais du connecteur natif, que j'avais
testé à sa sortie et retesté plus récemment, et auquel j'ai trouvé pas
mal de défaut, dont la rapidité. Ma solution a de plus l'avantage d'être
transposable à d'autres outils frontaux pour MySQL, comme HeidiSQL par
exemple, que j'utilise beaucoup pour l'apprentissage de SQL (infiniment
plus clair et plus convivial de construire une requête avec Heidi que
sous LibO – et je ne parle même pas d'Access dans ce cas).

La présence d'un SGBDR est une nécessité imposée par les programmes.
Idem si LibO abandonnait le module Base.

Comme l'a dit Cédric, on cherche pour LO une autre solution pour essayer

de remplacer hsqldb. Je vois du rapport du comité de pilotage qu'il serai
question de firebird, car il existe une version distribuée en MPL, donc une
licence qui va bien. Pour avoir utilisé une bdd firebird dans une
application embarquée au niveau professionnel, je sais que c'est un moteur
tout à fait capable. Reste à voir si cela est techniquement faisable.

Je ne connais que de nom, je n'ai pas eu l'occasion de l'essayer. Toute
solution sera valable, en ce qui concerne mes besoins. Mais j'admets que
dans le domaine spécifique de l'enseignement tertiaire, ces besoins sont
extrêmement limités.

Mon intervention ne fera pas avancer le produit malheureusement (manque
à la fois de temps et de compétences), c'est juste un avis.

Ce genre d'avis est très important pour rappeler qu'il existe des "volume

users" de Base, qu'on se le dise ! :-))

Merci de m'encourager à le donner, cet avis ! Je reconnais que la
limitation de mes besoins en matière de bases de données limite de fait
la portée de cet avis. Mes seules "justifications" sont le volume d'une
part, et d'autre part surtout le fait que l'abandon de cette
fonctionnalité dans Base me condamnerait de fait à abandonner l'ensemble
de la suite. Là, ça serait très regrettable, parce que je trouve à LibO
des qualités pédagogiques très intéressantes (surtout pour Writer), et
surtout beaucoup plus simples à expliquer et à mettre en œuvre que dans
Office.

Cordialement ;
Marc

#15

Bonjour ;

Bonsoir,

Merci pour ces précisions sur base, que j'aimerais utiliser de manière
plus régulière et plus professionnelle. Il est toujours intéressant de
connaitre les histoires du logiciel, et de cerner ainsi la route un
peu caillouteux de StarOpenLibreApacheOffice.org. (J'étais déjà
utilisateur de StarOffice à l'époche de StarDivision...).

J'ai eu une indication sur la liste DE de Robert Großkopf concernant
la connexion à une base locale MySQL (que je n'ai pas encore réussi),
mais j'ai d'énormes lacunes de connaissance de "base" ("fondamental"
et le logiciel lui-même).

Est-ce qu'il y a des cours d'initiations pour utiliser base
correctement ? Et surtout avec MySQL ? A tout hasard ?

Pour ce qui est d'utiliser LibO sous MySQL proprement dit, il n'existe
pas de tutoriel, du moins à ma connaissance). L'utilisation est
identique à celle d'une base sous moteur intégré, seules quelques
fonctionnalités ne son pas disponibles (pas possible de créer une base
ex nihilo par exemple). Pour ce qui est la connexion à partir de LibO
vers une base MySQL, j'ai en revanche un petit guide que je peux
t'envoyer. Il suffit que je le mette à jour (il date de 2007 et
concernait OpenOffice, il y a quelques différences notamment dans le
choix du mode de connexion). Je fais ça ce week-end et je te l'envoie.

Je veux bien mettre ce guide à la disposition de la communauté (s'il est
jugé suffisamment intéressant pour cela), mais je n'ai pas du tout le
temps de le mettre en forme sous la forme attendue pour la
documentation. Si quelqu'un accepte de se charger de cette mise en
forme, je lui envoie le document et les images originaux.

Marc

#16

Vraiement merci de ta réponse plus complète.

J'aime bien qu'on m'explique les choses dans le détails même si je n'y connait pas grand chose en informatique. Tu confirmes nos craintes pour l'avenir donc il faut qu'on se penche vraiement sur cette question. Il vaut mieux prévoir que guérir.

J'avais pensé au sous formulaire mais si les bases de données ne sont pas stables le problème sera le même et si j'ai bien compris il n'est pas sûr que les modules bases de données soient maintenus ou corrigés.

Donc dans l'immédiat, je continue avec FileMakerPro. Puis par la suite à moins que nous trouvions une autre solution nous nous dirigerons vers calc ou Excel sans formulaire de saisie. Nous avons l'habitude de nous servir d'Excel comme base de données avec des données très importantes puisque nous faisons de la saisie d'acte de naissances, mariages ou décès avec tout ce que ça comporte comme informations en autant de colonne que nécessaire et avec souvent plus de 6000 lignes. Un généalogiste ayant fait des macros qui nous permet d'avoir un cache de saisie très complet. Malheureusement je n'ai plus contact avec cette personne.

Bon, merci encore de tes réponses

à une autre fois

passes une bonne journée

Marie Jo

#17

Bonjour à tous ;

Pour moi, le souci vient plus de l'impact et éventuelles répercussions
que pourraient avoir les nouveaux développements de AOO, qui semblent
se pousser vers une espèce de fusion avec le code de Symphony qui,
rappelons-le, n'a pas de module de base de données spécifique. Pour
IBM, il est clair qu'un module Base, ils n'ont en rien à faire, et
heureusement il y a encore les anciens développeurs OOo (entre autres
maintenant chez IBM) qui militent encore en faveur du maintien du
statut quo de la fonctionnalité, mais il faut voir à la longue ce que
cela donnera. Même si on est des projets séparés, on voit bien qu'il y
a déjà une petite guéguerre au niveau des performances de la suite.
Qu'en serait-il pour LO, si AOO se débarassait de Base et découvrait
par la même occasion une amélioration fulgurante des performances ? Je
crois que la messe serait vite dite. Tout ceci n'est bien entendu
qu'une hypothèse parmi d'autres, j'espère qu'on me prouvera le
contraire et que Base continuera à évoluer... Alex

Si cela était le cas, Aoo serait totalement disqualifié dans le monde
l'éducation, du moins dans le secondaire et le supérieur technologique.
La présence d'un SGBDR est une nécessité imposée par les programmes.
Idem si LibO abandonnait le module Base.

Or, LibreOffice entre aujourd'hui dans les lycées en grande partie par
l'enseignement technologique, parfois par le professionnel, tous les
deux gros consommateurs de suites bureautiques. Tel qu'il existe
aujourd'hui, le module Base (plus Report Builder) constitue une
fonctionnalité suffisante pour couvrir les besoins de ces sections. Il
permet d'aborder pas mal de notions liées aux bases de données, depuis
l'étiquetage des champs jusqu'aux contraintes d'intégrité, en passant
par les notions de formulaire, de rapport, de requête en mode QBE et
SQL, et on n'en demande pas plus. Il ne permet pas de faire un
développement complet d'application (quoique, si elle est assez
simple...), mais ce n'est pas notre objectif. De plus la possibilité
d'utiliser Base en frontal vers des bases MySQL est extrêmement
intéressante, notamment dans les sections de technicien supérieur.

Vous direz que je prêche pour ma petite paroisse, et je vous l'accorde
bien volontiers. Je pense néanmoins que c'est un aspect à prendre en
compte : uniquement en ce qui concerne les établissements dont je
m'occupe, la suppression de Base entraînerait l'obligation de fait
(imposée par les programmes) de retourner vers Access, et personne ne
comprendra (ni n'admettra) qu'on ne prenne qu'Access dans la suite
Office. Et ça nous fait 400 postes et 2000 utilisateurs en moins pour
LibreOffice...

Il ne manque pas grand-chose à Base pour être une alternative valable,
du moins pour des applications simples pour une petite structure
professionnelle (je suis à peu près certain que ce que je demande à mes
étudiants de BTS est très largement au-dessus, en termes de complexité
et de fonctionnalité, de 80% des utilisations en petite entreprise, et
ce n'est pas très élaboré, croyez-moi). Il y a quelques bugs à corriger,
plus gênants que vraiment bloquants, quelques fonctionnalités à
intégrer, comme la possibilité de faire simplement des menus. HSQL est
un moteur qui n'est pas mal, même si je le trouve un peu trop chichiteux
sur le plan de la syntaxe (ça contraint les utilisateurs à de la
rigueur, ce qui n'est certes pas plus mal, mais trop chronophage).

Mon intervention ne fera pas avancer le produit malheureusement (manque
à la fois de temps et de compétences), c'est juste un avis.

Marc Romano

Bonjour à tous,

De plus la possibilité
d'utiliser Base en frontal vers des bases MySQL est extrêmement
intéressante,

C'est la solution que j'ai choisie et qui est somme toute très satisfaisante. Du côté serveur une base de données qu'on peut réellement administrer, du côté client LO qui permet de concevoir rapidement des formulaires et des rapports tout à fait présentables.

Bernard

#18

Tout à fait d'accord. Je le vois également dans une application de paye assez "musclée" dans laquelle il est embarqué et ça fonctionne très bien.

Je l'ai moi-même utilisé comme serveur non embarqué et je l'utilise encore occasionnellement avec LO pour quelques tests.

Bernard

#19

+1

#20

Bonjour Alex,

En fait, si j'ai bien compris, ça va encore plus loins que la juste la
gestion des dates, en ce que SQLite ne fait aucun typage de la plupart
des données, et du coup, les stocke dans ses structures internes sous
forme de chaînes de caractères (si je me suis exprimé correctement,
n'étant pas programmeur).

Oui c'est ca.

Espérons qu'une autre solution se présentera :-))

A priori firebird semble une alternative plus coherente a etudier plus
en profondeur. Sinon tout moteur de base de donnée embarquable ne
necessitant pas une Java Virtual Machine peut etre bon a etudier.