Alex Thurgood <[EMAIL PROTECTED]> écrit: > 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).
Pour avoir testé le Dbase, il y a plein de problème de format au milieu donc je comprends ton choix. Juste pour me revérifier, l'importation tu la fais en ouvrant sous Calc et en faisant un copier coller dans la table ? > > 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. Pour cette base là, cela ne me gêne pas. J'ai plusieurs bases en tête (certaines à migrer avec données inside et surtout une à refaire de zéro avec donnée outside) > > 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. Cela devrait pouvoir se faire avec une macro ? Faut que j'attaque ce coté là mais la déclaration de donnée est manipulable par les macros non ? > 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. Ok, j'attendrais qu'il me donne un avis. > 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. Voui, je crois qu'on partira sur de la base simple (on s'est donnée un an pour expérimenter) en espérant que l'on trouvera la solution à la séparation des données d'ici là. > >>> 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. A priori, on ne laissera les clés qu'à ceux qui en assumeront les risques, pour les autres on fermera la base (mot de passe ou autre) pour éviter de faire de l'assistance sur les fausses manip. > > 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. Va falloir que j'explore ces comment-faire. >> 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. Les données c'est "simple". Par contre les requêtes j'ai un doute de ce que j'ai entrevu et refaire les formulaires n'est pas si rapide. Si je devais parler en terme de part de marché, la reprise des bases Access permettrait la migration de tout ceux qui ont eu un stagiaire qui est passé par là, leur a développé un truc sous Access 2, Access 2000 et que l'on ne peut plus utiliser sauf sur le poste qui a gardé la bonne version d'Access. C'est la raison prinicipale pour laquelle je n'ai jamais voulu apprendre Access ni avancer sur ce truc (j'ai une autre bonne raison, ce n'est pas mon boulot ;-)) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
