Bonjour, Pour voir j'ai pris la base exemple et je me suis amusé à exécuter la requête de base qui permettrait d'obtenir les données que vous cherchez, à savoir
SELECT "nom", COUNT( * ) AS "Nb" FROM "absencesCsV2" GROUP BY "nom"; J'obtiens la listes des noms, mais sans regroupement aucun, chacun est mentionné autant de fois qu'il figure dans la table de base. Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf erreur c'est un problème lié à la version de HSQLDB, antédiluvienne. De là, il semble assez ambitieux de compliquer la chose pour demander à Base de fournir en plus par exemple la date de l'absence la plus récente… Pour vérifier au cas-où, j’ai créé une table « absences" sur mon serveur Postgres, et l’ai alimentée avec les données fournies. Si on exécute la requête ci-dessus (en fait sous cette forme : SELECT nom, count(*) FROM absences GROUP BY nom;) on obtient bien le nombre d’absences par personne, comme il se doit. Donc, on retombe toujours sur ce suivi des problèmes dans l’environnement LibreOffice. Si HSQLDB est un choix compréhensible dans le contexte des débuts, figer le moteur dans cette version archaïque est une décision hautement critiquable. Vouloir palier à ses insuffisances en passant à un autre moteur était compréhensible, mais Firebird est d’un autre calibre et me semble sortir de la cible bureautique. En clair, il est trop gros, trop pro pour la cible visée. Bref. N’est-il pas possible de fournir une version compatible SQL « normal » du moteur HSQLDB de Base, quitte à re-figer la situation pour les dix prochaines années ? Si je regarde la documentation de la version actuelle de HSQLDB, il semble que tout y soit pour gérer une base de données capable d’aider la gestion de très petites entreprises ou d’artisans. Il faut bien comprendre que structurer les données de gestion d’une entreprise sous la forme de tables normalisées est une approche très efficace, éprouvée. Ce n’est pas forcément dans le cloud, et tant mieux, car ainsi on ne dépend pas du réseau externe, on peut saisir ses factures le soir après l’activité sans redouter une coupure. Donc voir un moteur de base de données relationnelle dans une suite bureautique est une excellente proposition. L’état actuel de Base dans LibreOffice est paradoxal, car d’un côté on dispose de tout ce qu’il faut pour créer facilement des formulaires (saisie/consultation) et des rapports, de vérifier l’intégrité référentielle des données, mais on achoppe sur des trucs aussi basiques que cette syntaxe SQL défaillante, incomplète. C’est rageant. Note en passant : Les données fournies devraient être nettoyées. Stocker une date sous la forme « Le 09/12/20 » est une hérésie, le « Le » n’a rien à faire avec la choucroute et il empêchera une reprise « intelligente » de ces données pour les traiter comme des dates exploitables. En bref, il faut distinguer le fond de la forme, la donnée proprement dite de sa présentation. Une fois que la donnée est stockée proprement, on peut en faire ce qu’on veut en lui appliquant des directives de formatage. Sur ce, je passe la main aux gens compétents, jeunes et fringants de préférence ! Amicalement, Thierry, Homme de Gros-Mignon Le 20/10/2020 à 10:59, Stéphane Santon a écrit : > Le 20/10/2020 à 10:39, Stéphane Santon a écrit : >> Base jointe. > > https://www.cjoint.com/c/JJui607T1Un <https://www.cjoint.com/c/JJui607T1Un> > >> (j'ai renommé ma colonne 'id' par 'nom') > -- 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
