Le problème est bien là. Le temps qu'il faut y passer pour s'auto-éduquer, je dirai. Or, le temps je cours après.
Je vais néanmoins garder ton mail précieusement. Si j'arrive à voler un peu de ce temps précieux pour essayer de me plonger pour ce qui est véritablement du chinois pour moi.
Je suis sûre que OOo est superbe. (C'est comme pour le solaire. C'est une question d'idéologie. Mais il faut le temps pour y venir...)
Amicalement
Nathalie
----- Original Message ----- From: "Alex Thurgood" <[EMAIL PROTECTED]>
To: <users@fr.openoffice.org>
Sent: Friday, April 08, 2005 9:17 AM
Subject: Re: [users-fr] BD et champ mémo
Le jeudi 07 avril 2005 à 20:22 +0200, nathalie a écrit :
Bonjour,
Access fonctionne donc comme DBase avec DBF+DBT ?
Tout comme OOo : l'intégration du fichier DBT est transparent pour l'utilisateur pour autant que les deux fichiers résident dans le même répertoire.
On importe la base de
donnée et il se débrouille pour gérer ce qu'il trouve. Comment se peut-il
que OOo ne puisse pas faire pareil, puisqu'il est censé permettre le passage
d'Access à OOo ?
OOo se débrouille plutôt bien, seulement la représentation graphique n'est pas la même. Tu peux éditer ton champ memo au sein de ta table et les modifications seront écrites dans le fichier DBT. Cela a toujours fonctionné. Ce qui diffère, c'est que OOo ne te propose pas une représentation graphique comme celle que tu avais sous Access.
N'ayant jamais utilisé Access pour des choses sérieuses, j'ai fait mes premières expériences de front end graphiques BDD avec Lotus Approach, un produit qui devance largement OOo dans ce domaine (la représentation graphique des données, mais également les fonctionnalités autour du format dBase). Il faut bien admettre que les fonctionnalités de gestion des fichiers dbf sont relativement limitées dans OOo. Si on peut vivre avec ces limitations, on peut s'en sortir, mais de là à dire que OOo pouvait remplacer Access dans la gestion des dbf, il y a une certaine distance.
J'ai des bases de données énormes, toutes fonctionnent avec les champs mémos
puisqu'ils permettent l'équivalent d'une vingtaine de page de texte pour
chaque enregistrement. Cela allie l'intérêt de la Base de donnée pour les
renseignements courts et le traitement de texte pour les notes ou rappels
beaucoup plus longs.
Je ne me vois pas passer du temps à retravailler chacun d'entre eux, ni
bidouiller (du style copie du mémo dans la partie en bas pour pouvoir lire
et recopie si modification et remettre le tout dans la ligne mémo) pour
obtenir quelquechose d'à peu près semblable.
Un formulaire est une représentation graphique comme une autre. En outre, ton formulaire peut être stylé pour faire une représentation de table (on appelle ça un contrôle Table dans le jargon OOo), en choisissant les champs que tu veux faire apparaître dans cette table. Tu peux ajouter un autre contrôle dans le même formulaire correspondant au champ memo. Il n'y aura pas de recopie à faire, et tu te retrouves avec un fonctionnement comme sous Access. Une fois le formulaire enregistré, il servira pour tous les enregistrements. Je viens de faire le test avec une base DBF contenant deux champs MEMO, et ça marche sans soucis.
Alex
J'ai bien peur de devoir repartir chez microsoft si je ne trouve pas quelquechose de plus rapide.
Le temps que tu investis au départ est vite récupéré. OOo n'est pas dans sa version actuelle aussi puissant directement que Lotus Approach à cet égard pour l'utilisater lambda (je ne peux pas comparer avec Access), mais il est tout de même capable de rivaliser si on veut mettre un peu d'huile de coude.
La difficulté principale réside dans le fait que ces fonctionnalités de OOo étaient pensées au départ comme étant du ressort du développeur, et non de l'utilisateur de base. C'est pour cette raison que bcp de choses qui paraissent faciles sous d'autres produits concurrents semblent énormément difficiles à réaliser sous OOo.
Cela ne veut pas dire qu'il n'y pas de limitations dans OOo, il y en a, et notamment l'absence totale de fonctions pour DBF autre que COUNT, l'absence d'une vérification d'orthographe des données saisies, l'absence de vérification de la forme de des données saisies (par exemple dates) sans passer par des macros, toutes ces choses utiles qui se trouvent dans des produits concurrents (Claris Works, FileMaker Pro, Lotus Approach, MS Access, Paradox) et qui facilitent la vie d'un utilisateur au quotidien dans la construction de ses bdd. Une partie seulement de ces problèmes sera résolue avec la nouvelle version 2 qui va sortir en cours d'année, mais il reste à mon avis tout de même possible de faire des choses intéressantes pour autant que l'on se donne un peu la peine de s'y plonger.
Alex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
