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 ? ThierryLe ven. 26 oct. 2018 à 00:18, Eric Serafin <ericserafin@orange.fr <mailto:ericserafin@orange.fr>> 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, <demande_aide_fr@libreoffice.org <mailto:demande_aide_fr@libreoffice.org>> 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:: ericserafin@orange.fr <mailto:ericserafin@orange.fr> 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 à users+unsubscribe@fr.libreoffice.org<mailto:users%2Bunsubscribe@fr.libreoffice.org> 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 à users+unsubscribe@fr.libreoffice.org pour vous désinscrire Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/ Privacy Policy: https://www.documentfoundation.org/privacy