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.
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.
À (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é.
À 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.
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 ?
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).
Le wiki n'a apparemment rien sur Base. À part les anciens docs de OOo,
auriez-vous des conseils pour des lectures répondant aux questions
ci-dessus ?
Malheureusement, non. Il n'existe pas grand-chose à ma connaissance sur
Base. J'ai bien dans l'idée de créer quelques documents, mais c'est
encore à l'état de fantasme dans ma tête (comme participer davantage au
projet LibO). Un jour, ma retraite viendra...
Merci d'avance,
Henri
Si ces quelques indications peuvent t'aider, j'en suis heureux.
Cordialement ;
Marc
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
) ; j'ai maintenant compris ma principale erreur.