Le samedi 29 janvier 2005 � 18:38 +0100, Marie jo KOPP CASTINEL a
�crit :

> Quels retours d'exp�rience similaire avez vous et que me conseillez vous 
> de lui conseiller ?
> 

Bonjour,

J'ai des retours directs � t'offrir car nous utilisions FMPro au cabinet
sous MacOS 9. J'ai fait passer tout le monde, sauf qq MacOSX, sous
Linux. Pour l'instant, je passe par une �mulation Win4Lin avec FMPro
pour Windows pour certaines donn�es, en attendant d'avoir migr� toutes
les donn�es. Pour le reste, nous utilisons mysql et OOo.

La meilleure chose � faire est d'exporter les bases au format CSV. Cela
permet de garder les valeurs des champs "multivalu�s", chose qui n'est
pas possible si tu exportes en DBF. Ensuite, tu peux importer les
donn�es CSV directement dans la base mysql depuis la ligne de commande,
en sp�cifiant les s�parateurs et les champs de concordance. Cela oblige
parfois � repenser la structure de tes donn�es pour �viter un bazaar
lors de l'importation.

Si tu as des calculs dans ta base FMPro, il faut copier les d�clarations
ou req�etes et les r�impl�menter sous OOo sous forme de OOoBasic ou
requ�te SQL. C'est ce qui prend le plus de temps.

Le plus gros probl�me est qu'il est facile de faire une base de donn�es
relationnelle sous FMPro en qq clics de la souris. Malheureusement,
Apple a pris quelques libert�s avec le standard ANSI SQL en le faisant,
ce qui ne facilite pas les transferts, et �videmment la facilit� du
"tout graphique" a fait en sorte que nos bdd n'�taient pas bien
structur�es.

Je te d�conseille de passer par OOo pour l'import d'un CSV en source
StarCalc puis MySQL, car j'ai eu des surprises tr�s d�sagr�ables avec
m�lange de champs/donn�es en passant par l'autopilote. Sur quelques
enregistrements, cela peut �tre acceptable, mais sur plus de 3000 ce
n'est plus marrant. :-( J'ai m�me r�p�t� l'op�ration et ai pu reproduire
le comportement fautif.

M'enfin, �a avance petit � petit. L'un des gros d�fauts de l'interface
OOo actuelle est la recherche d'enregistrements avec les "jumelles" -
c'est tr�s, tr�s lent, et �a m�me lorsque la table est index�e sur le
champ unique autoincr�ment�. Il est de loin plus rapide de passer par
les req�etes, mais cela supposes que le personnel connaisse
l'utilisation de l'utilitaire graphique ou du langage SQL.


Alex



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Répondre à