Bonjour Thierry,
Cela a donc bien fonctionné avec Firebird.
Effectivement, la solution de réduire la taille des fichiers en les
éclatant est la plus adaptée. Je n'ai pas été rechercher dans les
paramètres de Firebird pour l'instant pour lui faire accepter des
fichiers plus volumineux. De plus, je risque de ralentir les calculs
alors que la méthode de scinder les gros fichiers est plus rapide.
Toutefois, même si les calculs ont été réalisés assez rapidement,
LibreOffice n'a toujours utilisé qu'un seul "core" de la machine. Lors
des calculs (plus rapides avec Firebird qu'avec HSQLDB) libreoffice.bin
n'a toujours utilisé qu'un huitième de la puissance du processeur. C'est
dommage. Je me doute que refaire les lignes de code pour les adapter à
du multithread doit être long et pas plus intéressant que ça. J'espère
que cela ne va pas pénaliser l'avenir de LO.
Si quelqu'un a des astuces sur la possibilité d'optimiser LO en
l'adaptant aux puissances de calculs de nos machines récentes, je suis
preneur.
Sinon, si vous avec des infos sur une évolution possible de LO pour une
future utilisation multicore/multithread, je suis très intéressé.
Merci encore pour toutes ces informations qui m'ont bien aidé à
travailler dans de meilleures conditions qu'avec HSQLDB.
Éric
Le 26/10/2018 à 08:22, Thierry Jeanneret a écrit :
Bonjour Eric,
A mon sens pour des volumes de cet ordre l'importation devrait se
faire par un bout de programme. Ça autorise un commit ligne à ligne et
une reprise éventuelle en cas d'erreur.
J'ai l'impression que le deuxième fichier s'est planté parce qu'au
collage l'importateur n'a pas réussi à déduire la structure du fichier
lorsqu'il a voulu créer la table. C'est pourquoi vous vous retrouvez
avec un record d'une ligne de 86892 caractères. Ou si vous avez
vraiment un champ de cette taille, il est préférable encore une fois
de passer par un bout de programme. Il me semble que Firebird peut
gérer de gros objets, ça dépend peut-être du type de champ choisi.
Je pense que la conversation peut se poursuivre ici, vous êtes sur un
forum d'entraide léger, des gens de bonne volonté.
Dites-nous ce qu'il en est ?
Thierry
Le ven. 26 oct. 2018 à 00:18, Eric Serafin <[email protected]
<mailto:[email protected]>> a écrit :
Bonsoir Thierry,
Et merci pour ta réponse rapide.
J'ai fait un test avec Firebird. Le premier fichier avec presque
37500 lignes et 10 colonnes a été importé avec succès par un
copier coller depuis un CSV ouvert par Calc. Par contre, le
fichier suivant qui est un xls ouvert aussi par Calc possède 801
lignes et 86 colonnes m'a envoyé un message d'erreur:
firebird_sdbc error:
*unsuccessful metadata update
*new record size of 86892 bytes is too big
Je n'avais pas eu ce problème avec HSQLBD.
La version de Firebird est la 3.01. Y a t'il un paramètre de
limite de taille des fichiers que l'on peut importer ? Dans
l'affirmative, comment le modifier si c'est possible ?
Dois-je ouvrir un autre fil de discussion comme le thème n'est
plus celui de départ ...
Merci d'avance pour les réponses que vous m'apporterez.
Éric Sérafin
Le 25/10/2018 à 23:25, Thierry Jeanneret a écrit :
Bonsoir,
Firebird, livré avec la branche 6.x devrait être bien plus rapide
que HSQLDB. Les formulaires et rapports sont peu intégrés, mais
si vous pouvez vous contenter du moteur et de SQL, vous devriez
vous y retrouver.
Sinon, verifiez toujours les indexes que vous définissez, c'est
fondamental.
Thierry
Le jeu. 25 oct. 2018 à 23:19, <[email protected]
<mailto:[email protected]>> a écrit :
Bonjour
Voici une nouvelle question envoyée à l'aide du formulaire de
demande d'aide
(http://fr.libreoffice.org/get-help/poser-une-question/).
Si vous répondez, merci de penser à utiliser la fonction
"répondre à tous" de votre logiciel de courrier électronique
de façon que le demandeur reçoive une copie de votre réponse.
Email:: [email protected] <mailto:[email protected]>
Sujet:: lenteur base
OS:: Linux
Version:: 6.1.x
Question:: Bonjour,
J'utilise LO Base pour créer des relations entre des fichiers
extraits de tableurs csv, ods ou xls. Je crée ensuite des
requêtes pour extraire des points communs ou des différences
entre ces fichiers (relations entre des noms, des codes, des
dates, etc). Tant que je travaillais sur des petits travaux,
je ne tenais pas compte du temps passé.
Hors, les derniers fichiers sont beaucoup plus gros et suite
à des lenteurs dans l'exécution de mes requêtes, j'ai vérifié
la charge du processeur et j'ai été surpris de voir que
libreoffice.bin n'utilisait qu'un seul des 8 coeurs/thread de
ma machine (processeur à 14% maxi d'utilisation par
libreoffice.bin). Je précise aussi que la machine est équipée
de 32G de RAM et entièrement en SSD rapides. Aucun autres
logiciels n'a apparemment ce problème sur ma machine.
J'ai essayé plusieurs versions de libreoffice depuis la 5.1 à
la 6.1. et toutes ont eu le même problème d'utilisation du
processeur. Je précise que je travaille avec des personnes
qui utilisent MS Access. Du coup, j'ai lancé le W10 que j'ai
en dual boot et essayé les mêmes requêtes avec MS Access. Le
résultats a été immédiat, je n'ai même pas eu le temps de
vérifier l'utilisation du CPU.
J'ai fait de nombreuses recherches aussi sur le net et n'ai
pas trouvé de solution.
Pouvez-vous, s'il vous plaît, m'indiquer s'il y en a une, car
je vais avoir des fichiers de plus de 45000 lignes d'une
centaine de colonnes à traiter professionnellement d'ici peu
et j'aimerai pouvoir continuer à utiliser LO ?
Je vous remercie d'avance pour l'aide précieuse que vous
pourrez m'amener.
Éric Sérafin
--
Envoyez un mail à [email protected]
<mailto:users%[email protected]> pour vous
désinscrire
Les archives de la liste sont disponibles à
https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy
--
Envoyez un mail à [email protected] pour vous désinscrire
Les archives de la liste sont disponibles à
https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy
