Re: [fr-users] [base] questions d'éternel débutant

Le 06/07/2012 06:27, Marc Romano a écrit :
> Bonjour, Henri ;
>
> Il est difficile de te répondre sans avoir les données elles-mêmes sous
> les yeux. Je vais essayer toutefois d'apporter quelques réponses simples
> aux questions les plus simples.
Bonjour Marc,

Merci pour ta longue réponse très détaillée. Je ne vais pas avoir le 
temps pour l'instant de l'exploiter, je vais m'y plonger dans trois 
semaines.
> Le 06/07/2012 01:30, Henri Boyet a écrit :
> > Quand je passe de Calc à Base, c'est-à-dire quand je crée un odb à
> > partir d'un ods, je n'arrive pas à mettre de clé primaire, ce qui est
> > apparemment indispensable pour créer des relations. Est-ce possible ?
> > Sinon, comment faire autrement qu'en créant "ex nihilo" et en retapant
> > 200 enregistrements avec de très nombreux champs ?
> Oui, c'est possible. Je suppose que tu passes par un simple
> copier/coller à partir de Calc dans Base, et je suppose de même que la
> première ligne de ta plage de cellule contient les noms des champs.
> Lorsque l'assistant d'importation te demande "Formatage de type", te
> permettant de choisir le format des champs dans Base, il suffit de faire
> un clic droit dans la fenêtre de gauche sur le champ qui doit devenir
> clé primaire dans Base et de sélectionner l'entrée "clé primaire" (il
> n'y a qu'une entrée, pas grand risque de se tromper...).
>
> Si la clé primaire de la table est composée de deux champs (clé
> concaténée) il faut sélectionner les deux champs (Ctrl + clic) avant de
> faire le clic droit.
En fait, lors de mes essais, je ne faisais pas forcément de 
copier/coller de Calc dans Base. Je ne me souviens plus pourquoi j'avais 
abandonné cette méthode, il me semble que c'était une question de 
formats des champs. J'avais essayé une autre démarche : créer une 
nouvelle base, se connecter à une base existante, tableur. C'est sans 
doute là que je n'avais pas de clé primaire. À creuser.
> > À (très) long terme, si j'arrive à créer quelque chose qui fonctionne,
> > je voudrais le proposer à mes collègues. Actuellement, chacun utilise
> > sa propre disposition de colonnes, ce qui ne facilite pas les
> > échanges. Est-il envisageable d'échanger des enregistrements ? A
> > priori, il faudrait transmettre les données de la table principale et
> > reconstruire les liens avec les tables secondaires (dont le contenu
> > change pour chaque collègue) ; Base est-il capable de s'y retrouver
> > dans les index ?
> Pas de réponse possible sans examiner les différentes sources. A priori,
> oui, mais en bricolant (et ça n'a rien à voir avec Base ou un autre
> outil, c'est une question de structure et de logique : un ordinateur est
> un tas de ferraille, il est rigoureusement incapable d'"interpréter" les
> données qu'il voit). Il serait infiniment plus simple que les tables
> secondaires aient la même structure, ça sera infiniment moins compliqué.
Je constate que je me suis mal exprimé. Je ne parlais pas d'échanges 
entre des bases de types différents mais entre des bases de mêmes 
structures. Supposons que la même commune a un emplacement différent 
dans la table «T_Commune» de deux utilisateurs différents. Si j'importe 
des enregistrements de la table «T_Eleves», le champ «Commune» ne 
contient pas le nom de la commune mais un index vers la ligne de la 
table «T_Communes». Que se passe-t-il puisque l'index ne pointe plus 
vers la bonne valeur ? Je ne sais pas si je suis clair…
> > À chacun de mes essais, je me suis rendu compte en cours de travail
> > (malgré une longue préparation sur papier) que j'avais besoin de
> > modifier la structure de la base, ce qui n'était plus possible (ou
> > plutôt, il aurait fallu utiliser des commandes SQL auxquelles je ne
> > comprenais rien). Est-il vraiment impossible de corriger simplement
> > des erreurs de conception ?
> Je ne vois pas quel est le problème. Si des liaisons ("relations", mais
> je n'aime pas le terme qui induit une confusion) ont été définies et que
> la modification remet en cause des l'intégrité des données, oui, c'est
> normal que ce soit refusé. Il faut dans ce cas supprimer les liaisons
> avant de faire toute modification de structure et les recréer ensuite.
>
> En y réfléchissant, il me semble avoir eu un problème similaire,
> précisément lorsque les liaisons sont définies. Base n'accepte plus de
> modification de structure dans ce cas. La solution est celle que je
> décris ci-dessus.
Ce n'était pas un problème de relations. Il me semble me rappeler que le 
problème principal était de rajouter un champ. Mais je n'arrivais pas 
non plus à corriger des formats de champs qui ne s'étaient pas importés 
correctement, en particulier les booléens.
> > J'utilise actuellement dans ma feuille de calcul des listes
> > déroulantes (merci Pierre-Yves !) qui vont piocher leurs valeurs dans
> > d'autres onglets. Est-il possible (facile ?) de créer plusieurs tables
> > liées à partir des différents onglets ? J'arrive bien à créer des
> > tables différentes mais elles sont dans des odb différents alors qu'il
> > faudrait qu'elles soient dans le même.
> Pour créer plusieurs tables par copier/coller à partir de Calc, il
> suffit de répéter l'opération dans Base, dans la même base de données.
> Sinon, je ne comprends pas ton problème. Peux-tu être plus explicite ?
C'est sans doute parce que j'avais abandonné la technique du 
copier/coller. Je créais donc une nouvelle base à chaque fois.
> > Je ne comprends pas les discussions sur tous ces moteurs internes,
> > externes… Concrètement, si je crée une base (sans doute avec la
> > version 3.6, je vais faire ça au mois d'août) et que le "moteur
> > interne" change dans un an ou deux, est-ce que je risque de ne plus
> > pouvoir travailler avec ma base ? Est-ce que les données enregistrées
> > avec le moteur interne peuvent éventuellement être traitées avec un
> > moteur externe ?
> Il existe plusieurs possibilités. Il est toujours possible de faire
> l'opération inverse à celle de la création des tables à partir de Calc
> (copier/coller de Base vers Calc), on récupère les données ce qui est
> quand même le plus important.
>
> La seconde est que les développeurs prévoient un outil de transfert des
> anciennes bases vers le nouveau moteur. Possible mais ça risque d'être
> un peu long à développer, il n'est donc pas certain que ce soit une
> priorité et je le comprends assez.
>
> La troisième est que dès le départ tu raisonnes avec un moteur externe,
> comme MySQL par exemple. Ce n'est pas très difficile à installer et à
> paramétrer, tu trouveras, ici ou sur les forums spécialisés MySQL,
> suffisamment d'aide pour le faire. Les avantages sont multiples : tu
> t'affranchis tout de suite du problème de compatibilité, tu peux très
> facilement passer d'une base personnelle à une base partagée par
> plusieurs en réseau, tu peux utiliser de nombreux outils (ex : Heidi
> SQL, très pratique) pour administrer simplement ta base (si LibO est
> performant en ce qui concerne l'exploitation des données, il l'est
> beaucoup moins pour l'administration. Ça n'a rien d'anormal, c'est même
> mieux comme ça).
J'avais acheté un livre qu'on m'avait recommandé, "Pratique de MySQL et 
PHP" mais ça dépassait mes capacités. Est-il possible d'utiliser MySQL 
sans PHP ?

...
> Si ces quelques indications peuvent t'aider, j'en suis heureux.
>
> Cordialement ;
> Marc
C'est un bon début, j'appellerai sans doute au secours en août.

Encore merci,

Henri



--
Envoyez un mail à users+help@fr.libreoffice.org pour savoir comment vous désinscrire
Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/users/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être 
supprimés