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: <[email protected]>
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]
