Patrick C. wrote:
Re,
Il est où ce doc ? Ce n'est pas dans son bien débuter il me semble.
Il doit être dans Docs & Files en attendant la relecture. Manuel l'avait
annoncé la semaine dernière sur la liste doc. Je n'ai plus le lien en
tête parce que j'ai fait du nettoyage dans mes mails.
Avec un connecteur, on retombe sur mes problèmes de connexion à un
fichier que je ne veux pas. Je veux bien un seul fichier à transmettre,
rien de compliquer pour mes utilisateurs. Mes bases sont soit du
FileMaker, soit de l'Excel.
Dans ce cas, il faut obligatoirement passer par l'étape "export" pour FM
et puis "import" des CSV (ou autre format que permet FM, mais de tous
je privilégie CSV pour les avoir essayés).
Voui mais pas de réseau, et je veux rester simple pour cette première
base, un seul fichier basique.
Dans ce cas, tu dois passer par le tout intégré et accepter que les
requêtes, données, formulaires, et (modèles de) rapports se retrouvent
tous dans un seul et même fichier a priori indivisible.
Par rapport à mon réve exprimé au dessus, jusqu'où puis-je aller ?
Tu peux séparer les formulaires du reste. Tu créés ton formulaire dans
le fichier ODB soit avec l'assistant, soit tout seul, puis tu fais
"enregistrer sous" et le sauvegarde en tant que fichier ODT. Le seul hic
c'est que tu es obligé de redéclarer la source de données (c'est-à-dire
le fichier ODB) au sein des propriétés du formulaire si tu l'ouvres
indépendamment (que ce soit sur ton poste ou sur un autre), sinon ton
formulaire sera inopérant.
Pour ce qui est de la comparaison et fusion des différents fichiers ODB,
je crois que Tony avait fait des essais il y a un certain temps pour
voir ce qui était possible, mais cela n'avait pas été très concluant,
voire ingérable à terme. Il faudrait qu'il se manifeste ici ou lui poser
la question, car je ne sais pas où il en est aujourd'hui.
Si je lui envoi les deux fichiers ensemble à mettre dans le même
répertoire, cela ne marche pas ?
Non, pas de manière automatique, du moins à ce que je crois savoir. Je
ne l'ai jamais expérimenté, car je suis juste en config réseau avec
serveur mysql. Je n'ai pas besoin ainsi de gérer la fusion entre
plusieurs fichiers ODB portant différentes modifs, requêtes,
formulaires, etc. Chacun fait ses propres requêtes si ça lui plaît, mais
les formulaires sont indépendamment utilisables et stockés sur le serveur.
Au départ, j'enverrai à tout le monde
un fichier avec le fichier de données vide.
C'est faisable, mais je ne vois pas comment tu vas gérer ensuite la
compilation des données utilisateur avec le ODB maître, sauf
éventuellement en bricolant un script pour jouer avec les fichiers xml
et sql à l'intérieur.
C'est un peu ce à quoi je pensais, il me restera à voir pour faire un
lien simple (non bousillable par mes maladroits).
Dès l'instant où l'utilisateur a le droit de modifer ou l'un ou l'autre,
voire sa config perso, ce risque existera toujours.
is.
Comment on fait ce type d'Addon ? Il est possible qu'on externalise ce
dont on ne se sent pas capable, mais j'aimerai en comprendre l'étendue
avant d'envisager des solutions.
Un How-to a été écrit pour ça, en tout cas, pour donner les bases de
départ. Je ne l'ai jamais fait.
La base est sans protection
aucune puisque j'ai réussi à faire quelques bidouilles légères. Mon
envie serait de la basculer entièrement en OpenBase (ie pas de connexion
dessus, même principe qu'au dessus). Je réve ou cela arrivera un jour ?
Faire une base Access depuis OOo n'est pas encore possible, il me
semble, et d'ailleurs, je ne pense pas que ce soit sur l'agenda des devs
(perso, je n'y vois aucun intérêt). L'accès à une base Access est déjà
possible, il semble également en écriture (sous Windows en tout cas, pas
sous Linux, du moins pas encore). Pour passer de Access à OOoBase, il
faut migrer les données, les requêtes et refaire les formulaires. Je ne
sais pas si cela changera de si tôt.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
