[Base] Requête SQL de comptage

Bonjour,

Base jointe.

https://www.cjoint.com/c/JJui607T1Un

(j'ai renommé ma colonne 'id' par 'nom')

Il faudra ajouter un champ 'ID' numérique qui identifie les enregistrements de manière unique.

Je comprends bien, mais il n'y a pas ça dans ma table de base qui est un export CSV.

L'instruction SQL pour faire la somme des absences attend plutôt une donnée numérique pour faire l'addiction.

La solution est donc de créer une (vraie) Base de données, de coller le csv dans cette Base pour créer une Table puis d’utiliser cette Table pour faire un Rapport.

Dans le Rapport, dans le Pied de page de Groupe, il faut insérer un champ Compteur qui va additionner le nombre de dates d'absence.

https://framadrop.org/lufi/r/PsYRdfrZpd#YKI/gNDYj1DQjuAxALexiFXXgHe5GDaF1kb+XRD16Ys=

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

J’exécute rarement des scripts d’origine étrangère sur mes machines.

Bonjour

Thierry Jeanneret wrote

Sur ce, je passe la main aux gens compétents, jeunes et fringants de
préférence !

Je réponds quand même...

Je tombe par hasard sur ce fil...

Thierry Jeanneret wrote

...
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 (1.8), alors que la
versions actuelle est 2.51.
...
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.
...
on achoppe sur des trucs aussi basiques que cette syntaxe SQL défaillante,
incomplète. C’est rageant.

Euh… tout ça ???

La base de données jointe est au format TEXTE et non hsqldb. Il est donc
normal de ne pas disposer des fonctions de groupe. Pour mémoire le format
est indiqué dans la barre d'état et dans Édition> Base de données> Type de
connexion.

On n'aurait pas non plus ces fonctionnalités avec un format classeur par
exemple.

Si on copie les données (+1 pour la remarque sur le contenu du champ
absences) dans une base hsqldb on a bien le résultat souhaité mais pas avec
ce qui est indiqué :

SELECT "nom", COUNT( "nom" ) "Nb" FROM "Table1" GROUP BY "nom"

Le résultat souhaité doit comprendre la date (même si on peut s'interroger
sur la pertinence du besoin).
Le résultat est obtenu avec une requête du type :

SELECT "nom", "date_absence", ( SELECT COUNT( "nom" ) FROM "Table1" "B"
WHERE "Table1"."nom" = "nom" ) "Nb" FROM "Table1"

Cela dit, puisque les données sont au format csv le plus simple serait de
faire ce traitement dans le tableur (sauf précisions manquantes).

Je vous laisse tirer vos conclusions...

Nouvelle_base_de_données.odb
<http://document-foundation-mail-archive.969070.n3.nabble.com/file/t246115/Nouvelle_base_de_données.odb>

Cordialement

Ce n'est un script, c'est une clé d'authentification de l'auteur du
message, si c'est de ça dont vous parlez.

Régis

C’est de ça. Ça s’envoie en public, ce truc-là ? J’y croyais pas...

Envoyé de mon iPhone

ben une clé publique a vocation à être publique, c'est un peu le
principe. Mais il faut une clé... privé, non diffusable pour la
déchiffrer... Si tant est que ce soit ça
de toute façon je doute que le message de David soit arrivé à beaucoup,
je ne l'ai pas reçu et je ne le vois pas dans les archives...
Uniquement dans les citations....
Claire

Bonjour Pierre-Yves et tous

merci pour ta réponse.
Je suis "de loin" ce fil car j'avoue que....

Bonjour

Thierry Jeanneret wrote
> Sur ce, je passe la main aux gens compétents, jeunes et fringants
> depréférence !

Je réponds quand même...
Je tombe par hasard sur ce fil...

Thierry Jeanneret wrote
> ...Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf
> erreur c'estun problème lié à la version de HSQLDB, antédiluvienne
> (1.8), alors que laversions actuelle est 2.51. ...on achoppe sur
> des trucs aussi basiques que cette syntaxe SQL
> défaillante,incomplète. C’est rageant.

j'ai effectivement été freinée dans mon usage de Base, à chaque fois
que j'ai voulu utiliser un peu de SQL...

Mais, comme tu le dis....

Euh… tout ça ???
La base de données jointe est au format TEXTE et non hsqldb. Il est
doncnormal de ne pas disposer des fonctions de groupe. Pour mémoire
le formatest indiqué dans la barre d'état et dans Édition> Base de
> Type deconnexion.
On n'aurait pas non plus ces fonctionnalités avec un format classeur
parexemple.

J'ai découvert trés récemment cette limitation qui est pourtant
parfaitement documentée. C'est trés simple de prendre du txt ou du csv,
du dbf pour en faire une base, mais les fonctionnalités sont de fait
plus limitées.
Est-ce qu'il existe (je n'ai pas cherché..) suffisament de doc pour
guider dans la conversion de base en format texte ou classeur vers
HSQLDB ? Est-ce que la doc Base 6.4 qui est en cours de traduction,
notamment par Jean Michel je crois, intègre cette info ?

@Thierry, pas d'accès concurrent avec Base à ma connaissance, ce qui
est aussi limitant. Ex : un formulaire de saisie (qui alimente la base
x) utilisable par 2 personnes en même temps...
Claire

Bonsoir,

Bonjour Pierre-Yves et tous

merci pour ta réponse.
Je suis "de loin" ce fil car j'avoue que....

Bonjour

Thierry Jeanneret wrote

Sur ce, je passe la main aux gens compétents, jeunes et fringants
depréférence !

Je réponds quand même...
Je tombe par hasard sur ce fil...

Thierry Jeanneret wrote

...Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf
erreur c'estun problème lié à la version de HSQLDB, antédiluvienne
(1.8), alors que laversions actuelle est 2.51. ...on achoppe sur
des trucs aussi basiques que cette syntaxe SQL
défaillante,incomplète. C’est rageant.

j'ai effectivement été freinée dans mon usage de Base, à chaque fois
que j'ai voulu utiliser un peu de SQL...

Mais, comme tu le dis....

Euh… tout ça ???
La base de données jointe est au format TEXTE et non hsqldb. Il est
doncnormal de ne pas disposer des fonctions de groupe. Pour mémoire
le formatest indiqué dans la barre d'état et dans Édition> Base de
> Type deconnexion.
On n'aurait pas non plus ces fonctionnalités avec un format classeur
parexemple.

J'ai découvert trés récemment cette limitation qui est pourtant
parfaitement documentée. C'est trés simple de prendre du txt ou du csv,
du dbf pour en faire une base, mais les fonctionnalités sont de fait
plus limitées.
Est-ce qu'il existe (je n'ai pas cherché..) suffisament de doc pour
guider dans la conversion de base en format texte ou classeur vers
HSQLDB ? Est-ce que la doc Base 6.4 qui est en cours de traduction,
notamment par Jean Michel je crois, intègre cette info ?

@Thierry, pas d'accès concurrent avec Base à ma connaissance, ce qui
est aussi limitant. Ex : un formulaire de saisie (qui alimente la base
x) utilisable par 2 personnes en même temps...
Claire

Soit dit en passant, il y a une solution très efficace et stable pour utiliser Base avec des requêtes SQL, c'est d'installer MySQL (ou MariaDB), un connecteur mysql (le connecteur jdbc marche très bien) et tout marche à merveille ! Evidemment, pas d'exportation possible, mais pour du publipostage c'est parfait.

Bonsoir,

Fil de discussion très instructif pour moi, le demandeur.

Hier soir j'ai trouvé sur un forum une requête avec COUNT(*)+1 qui fonctionne sur Base, et je me suis douté que la source CSV était la cause du mauvais résultat de HSQLDB 1.8.

J'ai essayé d'activer l'option "Avancé | fonctions expérimentales" en espérant faire tourner Firebird, mais sans succès.

Pour ce qui est de la date sous la forme "Le ...", c'est un peu simplifié mais c'est effectivement sous forme de texte.qu'est fournie la plage de dates.
Ceci vient d'un export CSV du logiciel de Vie scolaire "Pronote".
Je pourrais demander qu'ils incluent des champs supplémentaires un peu plus normalisés... pour une mise en place dans 18 mois.

Ma finalité, c'est que l'utilisateur.ice (un.e collègue) fasse le job en un minimum d'étapes :
- lancer l'export CSV Pronote et enregistrer le fichier CSV dans un dossier dédié,
- ouvrir un fichier Writer préparé pour le publipsotage lié au CSV,
- lancer les exports de publipostages individuels en PDF.

Re,

Pour en avoir le coeur net je viens de créer une table neuve, avec initialement deux colonnes : nom, date. Au cours de la création, HSQLDB exige une colonne d'index (normal en somme). Je l'ai donc laissé faire, en modifiant juste la propriété de la colonne ID créée en la mettant en incrément automatique.

J'ai alimenté cette table avec les requêtes suivantes, une légère extension du fichier .csv initial :

INSERT INTO "absences" ("nom", "date") VALUES ('Larry', 'Le 05/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 07/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 12/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 18/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 01/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 25/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 27/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 05/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 21/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 25/09/20');

A ce stade la table contient :

SELECT * FROM "absences"

2,Larry,Le 05/09/20,
3,Larry,Le 05/09/20,
4,Sarah,Le 07/09/20,
5,Sarah,Le 12/09/20,
6,Sarah,Le 18/09/20,
7,Sarah,Le 01/10/20,
8,Anna,Le 25/09/20,
9,Anna,Le 27/09/20,
10,Anna,Le 05/10/20,
11,Henri,Le 21/09/20,
12,Henri,Le 25/09/20,

Il y a deux "Larry" ensuite d'autres manipulations...

Manifestement, l'index doit lui plaire car j'obtiens ceci :

SELECT "nom", COUNT(*) FROM "absences" GROUP BY "nom";

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

Mais par contre, le format de sortie est incorrect, je ne vois pas pourquoi le nom est répété ni pourquoi il y a systématiquement une virgule en fin de ligne.

Si je modifie la requête ainsi :
SELECT "nom", COUNT(*) AS "cnt" FROM "absences" GROUP BY "nom";

J'obtiens ceci :

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

La renommage de la colonne COUNT(*) ne se fait pas, ce qui indique qu'il y a vraiment des trucs bizarres qui flottent dans le potage.

Bref, il semble qu'en créant une clé unique on parvienne à faire fonctionner partiellement les fonctions d'agrégation, mais franchement, je ne compterais pas trop dessus, d'autant plus si la sortie est choucroutée.

Peut-être qu'un jour, une nouvelle version, ou un autre moteur, qui sait... Moi, je m'arrête là pour ce sujet.

Ah, par contre si on veut connaître la date de la dernière absence de chaque élève, voici comment faire (ATTENTION, les DATES sont bien sûr traitées comme du TEXTE. D'où ma remarque précédente !) :

SELECT DISTINCT a."nom", a."date" FROM "absences" a  WHERE a."date" = SELECT MAX(b."date") FROM "absences" b WHERE a."nom" = b."nom";

Anna,Le 27/09/20,
Henri,Le 25/09/20,
Larry,Le 05/09/20,
Sarah,Le 18/09/20,

Il y a toujours des virgules en trop, mais bon.

Bonne fin de journée,

Thierry

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.

Normal, avec des tables texte, l'agrégation n'est pas possible. Mais la doc en français est (encore) inexistante, je suis en train de la traduire)

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…

Eh bien oui, c'est une erreur, et ce n'est pas lié à cette version, qui, bien qu'antédiluvienne, fonctionne parfaitement, et permet des requête bien plus complètes.

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.

Si on pouvait éviter ce genre de jugement à l'emporte pièces. Ce qui y est n'est pas bien, ce qui va le remplacer est trop gros, ...

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.

C'est tout à fait le cas actuellement.

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.

Voir ci- dessus. Dans de "bonnes" conditions, ça fonctionne.

...Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf
erreur c'estun problème lié à la version de HSQLDB, antédiluvienne
(1.8), alors que laversions actuelle est 2.51. ...on achoppe sur
des trucs aussi basiques que cette syntaxe SQL
défaillante,incomplète. C’est rageant.

j'ai effectivement été freinée dans mon usage de Base, à chaque fois
que j'ai voulu utiliser un peu de SQL...

Voilà qui m'étonne. Ce serait lié à quoi ?

Dans les fichiers d'exemples que je suis en train de traduire, je trouve des usages de SQL (et qui fonctionnent) que je ne soupçonnais pas. Mais je ne suis pas un spécialiste, juste un amateur un peu éclairé...

J'ai découvert trés récemment cette limitation qui est pourtant
parfaitement documentée. C'est trés simple de prendre du txt ou du csv,
du dbf pour en faire une base, mais les fonctionnalités sont de fait
plus limitées.

A mon avis, cette fonctionnalité est implémentée pour faciliter l'usage des sources de données et quelques traitements simples. Mais certainement pas à recommander.

Je rappelle que la question initiale était : "grouper les absences d'un élève sur une seule page" à partir d'un fichier CSV. J'ai donc répondu à cette question, en faisant simple, sans créer de base intégrée.
J'étais loin de me douter qu'on partirait dans des comptages SQL !

Est-ce qu'il existe (je n'ai pas cherché..) suffisament de doc pour
guider dans la conversion de base en format texte ou classeur vers
HSQLDB ? Est-ce que la doc Base 6.4 qui est en cours de traduction,
notamment par Jean Michel je crois, intègre cette info ?

Il n'y a pas plus. J'ai réalisé il y a quelque temps un outil pour exporter une feuille Calc en requête SQL, mais ça n'a intéressé personne. Il fallait de toute manière créer la base intégrée avant l'import SQL.

@Thierry, pas d'accès concurrent avec Base à ma connaissance, ce qui
est aussi limitant. Ex : un formulaire de saisie (qui alimente la base
x) utilisable par 2 personnes en même temps...

Il y a une bidouille possible en créant des comptes dans HSQLDB, mais je n'ai jamais testé, et je doute un peu de l'intégrité des données... Ça fait partie des tests que j'aimerais bien faire. Cela dit, un serveur Mysql (ou MariaDB) sur un poste du réseau utilisé avec Base sur plusieurs postes, ça fonctionne bien aussi.

Bonne soirée à tous...

Pour ce qui est de la date sous la forme "Le ...", c'est un peu simplifié mais c'est effectivement sous forme de texte.qu'est fournie la plage de dates.
Ceci vient d'un export CSV du logiciel de Vie scolaire "Pronote".
Je pourrais demander qu'ils incluent des champs supplémentaires un peu plus normalisés... pour une mise en place dans 18 mois.

Si les dates ne sont pas au format Date dans la base, pas de tri possible...

Ma finalité, c'est que l'utilisateur.ice (un.e collègue) fasse le job en un minimum d'étapes :
- lancer l'export CSV Pronote et enregistrer le fichier CSV dans un dossier dédié,
- ouvrir un fichier Writer préparé pour le publipsotage lié au CSV,
- lancer les exports de publipostages individuels en PDF.

Avec le projet complet, on voit mieux où il faut aller !

Pronote ne fait pas des rapports sur les absences ?

Bonne soirée,

Bonsoir,

Re,

Pour en avoir le coeur net je viens de créer une table neuve, avec initialement deux colonnes : nom, date. Au cours de la création, HSQLDB exige une colonne d'index (normal en somme). Je l'ai donc laissé faire, en modifiant juste la propriété de la colonne ID créée en la mettant en incrément automatique.

J'ai alimenté cette table avec les requêtes suivantes, une légère extension du fichier .csv initial :

INSERT INTO "absences" ("nom", "date") VALUES ('Larry', 'Le 05/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 07/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 12/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 18/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 01/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 25/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 27/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 05/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 21/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 25/09/20');

A ce stade la table contient :

SELECT * FROM "absences"

2,Larry,Le 05/09/20,
3,Larry,Le 05/09/20,
4,Sarah,Le 07/09/20,
5,Sarah,Le 12/09/20,
6,Sarah,Le 18/09/20,
7,Sarah,Le 01/10/20,
8,Anna,Le 25/09/20,
9,Anna,Le 27/09/20,
10,Anna,Le 05/10/20,
11,Henri,Le 21/09/20,
12,Henri,Le 25/09/20,

Il y a deux "Larry" ensuite d'autres manipulations...

Manifestement, l'index doit lui plaire car j'obtiens ceci :

SELECT "nom", COUNT(*) FROM "absences" GROUP BY "nom";

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

Mais par contre, le format de sortie est incorrect, je ne vois pas pourquoi le nom est répété ni pourquoi il y a systématiquement une virgule en fin de ligne.

Là, je suis d'accord. Mais ceci survient en utilisant Outils/SQL et en affichant la sortie des instructions "Select" ?
Parce qu'en enregistrant la requête, le résultat au format table est conforme.

Si je modifie la requête ainsi :
SELECT "nom", COUNT(*) AS "cnt" FROM "absences" GROUP BY "nom";

J'obtiens ceci :

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

La renommage de la colonne COUNT(*) ne se fait pas, ce qui indique qu'il y a vraiment des trucs bizarres qui flottent dans le potage.

Bien sûr que si, si on regarde la requête au format table, après avoir créé la requête. Pas en exécutant pas Outils/SQL, bien entendu.

Au passage, tiens, le GROUP BY tout pourri s'est mis à fonctionner ?

Bref, il semble qu'en créant une clé unique on parvienne à faire fonctionner partiellement les fonctions d'agrégation, mais franchement, je ne compterais pas trop dessus, d'autant plus si la sortie est choucroutée.

Si, si, ça fonctionne parfaitement, en utilisant les requêtes, qui sont faites pour être enregistrées et utilisées plus tard dans des formulaires ou des rapports.

Peut-être qu'un jour, une nouvelle version, ou un autre moteur, qui sait... Moi, je m'arrête là pour ce sujet.

Il vaut mieux, car ça donne une (fausse) image négative ce ce logiciel.

Ah, par contre si on veut connaître la date de la dernière absence de chaque élève, voici comment faire (ATTENTION, les DATES sont bien sûr traitées comme du TEXTE. D'où ma remarque précédente !) :

SELECT DISTINCT a."nom", a."date" FROM "absences" a  WHERE a."date" = SELECT MAX(b."date") FROM "absences" b WHERE a."nom" = b."nom";

Anna,Le 27/09/20,
Henri,Le 25/09/20,
Larry,Le 05/09/20,
Sarah,Le 18/09/20,

Et comme les dates sont au format texte, le résultat est faux. Avec des dates au bon format, le résultat est correct.

Bonne soirée,

--

Jean-Michel Coste

Bonsoir,

Après une petite réflexion sur le sujet, pour faire le plus simple pour l'utilisateur (à mon sens, bien entendu), je créerais d'abord une table  avec Nom, Prenom, Absence_1, Absence2, .... Absence_15 (il m'a semblé qu'il y avait un maximum de 15?).

Puis, par macro ou requête, en parcourant la table originale, remplir cette nouvelle table (après l'avoir vidée de la session précédente, bien entendu). On a donc une ligne par élève, avec toutes ses absences. Après ça, le publipostage est très facile, puisqu'il suffira d'intégrer le nom et les 15 champs (dont une grande majorité sera vide) dans la page adéquate du document final.

Le plus difficile sera peut-être de lancer la procédure sans utiliser Base (la base devra être la, de toute façon).

Il y a peut-être une solution directe avec Calc, ou tout simplement une macro, qui, traitant le fichier CSV, fabrique un autre CSV au format de la fameuse table définie ci-dessus, le publipostage à partir de ce fichier est aisé également.

Je retourne contempler les vagues avec mon vélo pour quelque temps.... mais le problème m'intéresse.

Bien cordialement,

Bonjour,

Je rappelle que la question initiale était : "grouper les absences d'un élève sur une seule page" à partir d'un fichier CSV. J'ai donc répondu à cette question, en faisant simple, sans créer de base intégrée.
J'étais loin de me douter qu'on partirait dans des comptages SQL !

Alors... La question était :
Dans un publipostage (fonctionnalité pour laquelle j'utilise encore Word), fusionner sur une page tous les enregistrements qui ont une valeur de champ en commun.

"Publipostage" étant une fonctionnalité à mon avis clairement définie sous LO.

Désolé de ne l'avoir écrit que 2 fois, et pas assez explicitement.

Bonsoir,

SELECT "nom", COUNT( * ) AS "Nb" FROM "absencesCsV2" GROUP BY "nom";

Normal, avec des tables texte, l'agrégation n'est pas possible. Mais la doc en français est (encore) inexistante, je suis en train de la traduire)

Ben voilà la cause de base de toutes ces questions. Voilà. Voilà.

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.

Eh bien oui, c'est une erreur, et ce n'est pas lié à cette version, qui, bien qu'antédiluvienne, fonctionne parfaitement, et permet des requête bien plus complètes.

Bien plus complètes, SAUF avec des tables texte.

Bonsoir,

Ma finalité, c'est que l'utilisateur.ice (un.e collègue) fasse le job en un minimum d'étapes :
- lancer l'export CSV Pronote et enregistrer le fichier CSV dans un dossier dédié,
- ouvrir un fichier Writer préparé pour le publipsotage lié au CSV,
- lancer les exports de publipostages individuels en PDF.

Après une petite réflexion sur le sujet, pour faire le plus simple

Puis, par macro ou requête, en parcourant la table originale, remplir cette nouvelle table (après l'avoir vidée de la session précédente, bien entendu). On a donc une ligne par élève, avec toutes ses absences. Après ça, le publipostage est très facile, puisqu'il suffira d'intégrer le nom et les 15 champs (dont une grande majorité sera vide) dans la page adéquate du document final.

Il y a peut-être une solution directe avec Calc, ou tout simplement une macro, qui, traitant le fichier CSV, fabrique un autre CSV au format de la fameuse table définie ci-dessus, le publipostage à partir de ce fichier est aisé également.

C'est tout le dilemme du projet :

- OU je trouve une solution intégrée avec une suite bureautique qui est :
   1. simplissime à mettre en place pour l'utilisateur Lambda ET
   2. facilement transmissible car sans macro ou fonctionnalité au-delà de la bureautique

- OU je pars dans du traitement personnalisé de données avec scripts nécessaires et là je passe tout de suite en Javascript sur des Google Sheets avec GSuite Education.

Bonjour,

Merci de l'aide. La colonne 'Qte' reste toujours vide.

Même avec un simple
SELECT
    "nom", "date_absence",
    ( SELECT COUNT( * ) FROM "absencesCsv2" ) "Qte"
FROM "absencesCsv2"

la colonne 'Qte' reste vide...

Voilà, comme vous avez pu le lire et l'apprendre peut-être comme moi, les requêtes de Base sur les tables texte de type CSV sont très limitées, notamment Group by qui n'est pas fonctionnel.

En fait une solution intermédiaire serait de créer une base HSQLDB, puis une table avec la structure du fichier CSV, puis les requêtes ;
pour mettre à jour le contenu de la table à partir d'un nouveau fichier CSV, lancer la requête (Outils | SQL...) :

SET TABLE "absences" SOURCE "absencesCsv2.csv"

Sans clé primaire aucune, les requêtes attendues fonctionnent.